Называете класс CurrentUserSingleton и проблем точно не будет

Вы меня явно недооцениваете :)

А кроме шуток — вот уже не первый раз в итоге скатываюсь к тому, что DI + Registry наше все.
Тут нам и ре-юзабельность малой кровью, и возможность моки подпихивать и черт в ступе, если нужен.

Получается, к сожалению, такой если не god-object, конечно, но просветленный — это точно, но ничего не поделать, где-то в системе должны же зависимости хранится.

Так яж про семантику.
user = new User # as singleton — плохо
user = Registry.get 'current_user' — хорошо

Использование синглтона как раз и отражает первую проблему в программировании — называние вещей.

Эмм… как это не важно? Объект он на то и объект, что обладает собственной «уникальностью» (ну, в грубом приближении). И когда мы создаем новый — он должен быть новым.
А то потом получаем всякое, что у Пети пол женским стал, потому что кто-то новую запись сделал, взяв как конструктор объект пользователя.

Синглтон — дурацкий антипаттерн, убивающий читабельность и понимабельность кода чуть более, чем совсем.
Тот факт, что мы получаем ссылку не должне скрываться за декларацией создания нового объекта, это просто ложное утверждение, типа true = false # Happy debugging!.

Правильно использовать #clone() или фабрику объектов.

Да не за что, жадность — первое на чем вечно накалываешься :)

О парсинге HTML, тут кабэ такая мыслишка — я не говорю о том, что это невозможно регулярками — они неплохо с этим справляются и частенько парсеры внутри себя их и используют.

Я о том, что в реальном мире HTML вполне вероятно может оказаться сломанным и все пойдет плохо. Суть парсеров в том, что их писали реально мозговитые ребята (уж точно поумнее меня) и они с этой проблемой так или иначе боролись. Тесты, документация и т.д. — это блин непросто все. Так что лучше взять готовое.

Оххх.
(<([a-z]+[^>]*)>)(.*)(</\2>) -> (<([a-z]+[^>]*)>)(.*?)(</\2>)

Но вообще парсить HTML регулярками черевато :)

Java(+Spring) :)

О, там да, там офигенски все просто. Пишем простыню XML-я и все заработает. И еще фабрики фабрик фабрик.
Этой астронавтикой можно только на чужие большие бабки развлекаться, за свои уж лучше что попроще.

Вы действительно считаете, что это проще, чем вместо function f(x) написать int function f(float x)?

Оооо… Так, последний раз, мессадж такой — пока вы кодите в песочнице у вас вся эта фигня работает. И рождает чувство ложной безопсности.
Как только код становится модулем и его зовет кто-то сторонний, в реальном мире — оно становится дырявым и фейлится. Это раз.
Тесты, ассерты и т.д. писать все равно придется, их объявление типа не отменяет. Хотя, можете не писать, дело ваше.

Там же есть корявый JS github.com/Meettya/clinch/blob/master/lib/file_processor.js#L57

Исчо раз — в JS можно сделать true AOP, для того есть всякие модули, но по мне вся эта фигня уменьшает читаемость кода, как и миксины. Только миксины — неизбежное зло, а вот аспекты можно и упростить.

Мысль короче такая — нафик не нужен этот TS, он замыкает на себя разработку и по факту ничего не гарантирует. Нужны проверки — их есть в JS. Все.

Обычный CoffeeScript синтаксис, добавьте в стакан немного скобокочек и кавычечек и получите JS.

Я бы сказал это аспект в его истинной форме, после того, как какой-нить метапроцессор обработал наш исходник и вставил вызовы функции туда, где они нужны. Ведь именно это и происходит на самом деле.

Ничто не мешает использовать AOP-фреймверки для JS, но лично мне они кажутся оверкильными и ухудшающими понимание где и что происходит с кодом.

Так что если отбросить всю мишуру — это аспект. Или метод-декоратор. Оно просто работает.

Таки гимор-то где? Почему эта конструкция не может быть использована там, где нам нужна проверка типов или что там еще надо проверить?

Практика заворачивания в аспект — github.com/Meettya/clinch/blob/master/src/file_processor.coffee#L42

rejectOnInvalidFilenameType = (methodBody) ->
  (filename, cb) ->
    unless _.isString filename
      return cb TypeError """
                must be called with filename as String, but got:
                |filename| = |#{filename}|
                """
    methodBody.call @, filename, cb

<..somewhere in class...>

loadFile : (rejectOnInvalidFilenameType (filename, cb) ->
  <...method body...>
)

гиде гемор?

Ага, правда в половине случаев придется кастовать, потому что «ну так надо» и придумывать велосипеды, как бы эту проверку побороть.
И потом, если что-то не покрыто тестами и вылезло в деплое — ССЗБ.

Исчо раз повторяю — если нужна проверка типов — заверни в аспект. Если нужнен конкретный тип — заверни в аспект.

В 80% случаев мне нужна гибкость.
Обычно мои методы ловят массив или скаляр, который заворачивают в массив — вуаля, понятный интерфейс готов.
Хошь foo('bar'), хошь foo(['fizz','baz']).

Кроме того, вся эта магия с типами будет работать только внутри MS-го варианта. Как только ты сделал из своего кода либу и упаковал в JS — пуффф, магии больше нет. И отгруженная либа, которую вызывает кто-то еще в JS-е становится нифига не безопасна, а вот если все в аспектах было — все ок, аспект он и в Африке аспект.

Этож очевидный косяк.

Класс! Здорово сказано.

А я вот никогда на типизированных языках и не писал и вообще не понимаю, о чем хомяки плачат — ну нужна тебе проверка — ну оберни ты в декоратор метод и проверть что он у тебя там получает. Это реально нужно настолько редко, что просто не о чем говорить. И тестами прокрой. Все.
Хороший код можно писать на чем угодно и типизированный язык не гарантия хорошего кода. Все дело в программере.

А что именно под контрактом подразумевается?

При таких объемах надо разводить руководство на че-то типа www.simmtester.com/page/products/sp3000/sp3info.asp или www.memorytesters.com/ и тестировать на потоке.

ХМ… ИМХО тогда проблема скорее в менеджменте и програмно она точно не решается :) Да и аппаратно не все так просто :)

Забавный метод, но ИМХО 4-8-портовый KVM надежнее. Они вменяемых денег стоят, если без наворотов.
Типа D-LINK DKVM-4K.

настроенный express под node,js + плагин LiveReload (который бесплатный) — и правь в любом редакторе хоть Coffee, хоть Stylus, хоть Jade :)

Done, v 0.2.9 в js варианте, правда из npm пакета я src не выкидываю никогда, потому как у меня тесты на него завязаны.

А… хм, как-то все время вылетает из головы, что не у всех npm install coffee-script -g :)

Точно, перепакую сегодня, спасибо за напоминание.