github.com/kekekeks/NotifyHelper — выложил тут. А, да. Оно сделано так, что дата биндинги не отваливаются после обфускации — если генератор видит атрибут PropertyName, то не только будет использовать его как имя для события, но сгенерирует в итоговом классе свойство с таким именем, которое в дальнейшем доступно через Reflection.
Да и в асинхронном стеке ASP.NET 4.5 это уже есть. Только в отличие от node.js в рамках одного процесса работают несколько воркеров, являющихся тредами из стандартного пула. Подозреваю, что абсолютно точно так же сделано и в яве.
Остаётся тогда только один существенный недостаток — невозможность нормальной обработки исключений, вызванных асинхронными операциями. Хотя, можно их оборачивать, но это уже не так красиво выглядит.
Да, чем-то похоже. Но ради одного INotifyPropertyChanged городить целый post-build таск? У меня для этих целей Reflectiin.Emit-кодогенератор на коленке за пару часов написанный используется сто лет уже.
О стоимости PostSharp. АОП обычно прикручиваю с рантайм-кодогенерацией классов-врапперов. Дёшево, сердито, отладочные символы не портятся, готовые решения есть.
Для дотнета есть штука под названием PostSharp, которая встраивается как постсборочный таск и преобразует атрибуты аннотаций в исполняемый код. Помимо стандарных ассертов можно делать свои атрибуты с обработчиками, вызываемыми на входе и на выходе из функции, таким образом привнося в язык аспектно ориентированное программирование. Причём даже вносит правки в отладочные символы. Стоит, правда, как авианосец, так что в боевых проектах пока не пробовал.
Не создаёт. Почитайте, как оно внутри работает. Вкратце: по завершению асинхронной по своей природе операции (файловый/дисковыйввод-вывод) обработчик её результата вызывается в контексте синхронизации, из которого эта операция была инициирована. В случае веб-приложения этому контексту соответствует «любой поток из стандартного пула потоков», но можно реализовать свой контекст и сделать обработку принудительно однопоточной, однако, такой вариант видится неэффективным на многоядерных процессорах. С самой же асинхронной операцией (которая на самом деле Begin/End с IAsyncResult, обёрнутая в таск) никаких потоков не сопоставлено, в Windows её окончания ожидают через I/O Completion Port, в никсах Mono держит отдельный поток, который ждёт событий через epoll/kqueue и передаёт эти события куда следует.
возможно на порядок больше, чем вы могли бы получить, используя PHP, .NET или RoR
Эм. В дотнете уже года полтора как есть поддержка удобной (неудобная в виде Begin/EndSmth с колбеками и IAsyncResult была с бородатых времён) асинхронщины в виде async/await, которая позволяет писать код в императивном стиле абсолютно точно не блокирует вызывающий поток, и на тысячи запросов в секунду будет хватать пула из пары десятков потоков. Стек ASP.NET 4.5 и ASP.NET MVC 4.0 этот подход дают с успехом использовать. Единственная проблема — ещё не все ORM и коннекторы к БД это поддерживают.
1) сборка может быть отладочной и релизной, отличие релизной в том, что в результате применения оптимизаций строки могут не всегда корректно определяться.
2) отладочная информация находится в лежащих рядом со сборками pdb(mdb в случае использования компилятора dmcs), которые с приложением обычно не поставляют, впрочем, в случае веб-приложений это не составляет проблем
Ещё можно купить уже решарпер и разметить код аннотациями. Тогда тот сам будет подсказывать, откуда можно ждать null, и ругаться при попытке передать его не туда, куда нужно.
2) отладочная информация находится в лежащих рядом со сборками pdb(mdb в случае использования компилятора dmcs), которые с приложением обычно не поставляют, впрочем, в случае веб-приложений это не составляет проблем