По поводу C#: если Вы поразмыслите чуток как почему это работает в python, то возможно осознаете, что эта фича хорошо всписывается только в динамические языки ;))) В C# пришлось бы делать медленный вызов через механизм отражения или генерировать много call-site кода ради сомнительной удобности :) Да ещё и обратите внимание, что в python нету перегрузки методов как таковой ;)
Да просто рано ещё таким библиотекам появляться. Задача достаточно трудоёмкая, в Microsoft.CSharp.dll по сути зашиты все правила C# overload resolution, реализовано call-site кэширование и много другого прочего…
Ко-/контравариантность будут работать во всех аспектах, кроме рантаймных.
Дело в том, что ко-/контравариантность введена на уровне рантайма .NET 4.0, теперь опкоды MSIL, такие как castclass и isinst (операторы as и is в C#) считают, например, что IEnumerable<string> можно скастить в рантайме к IEnumerable<object>.
То есть в .NET 3.5 можно переменной IEnumerable<object> присвоить IEnumerable<string>, но вот xs is IEnumerable<object> (при переменной IEnumerable<string> xs) будет возвращать false.
То есть полного поведения .NET 4.0 при компиляции под .NET 3.5 получить не получится.
dynamic — нет, он требует сборку Microsoft.CSharp.dll, которая есть и будет только для .NET 4.0. Но реально написать свою такую же для .NET 3.5, возможно в скором времени появится аналоги Linq bridge, только для dynamic.
* Запретить optional parameters для override-методов — почему должна быть нарушена некая «консистентность», чем они хуже невиртуальных методов?
* Требовать в override указывать точно такое же значение — значение по-умолчанию может быть достаточно сложно в записи и требование от юзера копипасты не выглядит верным решением.
* Забирать из метаданных переопределяемого метода значение по умолчанию и запретить задавать другое — возможно это было бы лучшим решением. Но интересно, могут ли быть реально обоснованные причины изменять значение по умолчанию в override?
Не думаю, что это всё вообще будет составлять проблему, так как в C# значительно лучше развит intellisense, который при вызове всегда покажет какое значение реально будет использовано :)))
В рефлекторе видно так: void Foo([Optional, DefaultParameterValue(true)] bool ensureIsUpToDate)
В C# 4.0 точно такое же поведение, как в C++. Будет подставлено значение по-умолчанию от метода, определённого в типе, который будет известен статически на момент компиляции, то есть в Вашем случае известно будет что a — типа A и подставлено будет 0.
Обратите внимание, что компилятор C# 4.0 при компиляции под .NET 3.5 и ниже не будет автоматически генерировать перегрузки метода с параметрами, указанных как необязательные (достаточно много пользователей ожидали такое поведение). Однако он будет отмечать параметры псевдоатрибутом [System.Runtime.InteropServices.Optional] и вписывать в метаданные параметров их значения по-умолчанию, что позволит воспользоваться ими в языках для CLR 2.0, поддерживающих необязательные параметры.
Если честно, то ожидал немного большего :))
Имхо тема Rx не раскрыта, если бы сам не поиграл с Rx, то после подкаста желания, наверное, не возникло бы, так как просто не понял бы зачем оно мне надо в real life. Много неточностей, например, IDisposable, возвращаемый при подписке, никоим образом не связан с weak events pattern, это просто способ отписки от observable последовательности и высвобождения ресурсов (и в этом большой бенефит Rx, так как обычно подписываясь лямбдами на события, их потом хрен отпишешь, так как нужен абсолютно тот же экземпляр делегата, а тут лишь .Dispose() дёрнуть надо). Мало сказано про интерфейсы и их контракт, про дуализм с IEnumerable… А вот комбинаторам достаточно внимания им уделили и вцелом хорошо осветили.
Но всё равно вы очень крутые, послушал вас с удовольствием и дальше буду слушать, так держать!
Определите своё field-like событие и оно там будет, в BCL многие события описаны вручную и не используют синхронизацию, так как по сути многие из них описаны в классам, которые не являются потокобезпасными по спецификации, и им эта синхронизация в акцессорах нафиг не нужна. В случае field-like событий, компилятор C#, по сути, не спрашивая Вас эмитит синхронизацию.
К сожалению, действительно всё же существуют ситуации, когда момент отписки не может быть детерминирован и в этих случаях weak events — единственный способ исключить утечки памяти. К примеру, WPF имеет специальные средства для работы со слабыми событиями (см. наследников System.Windows.WeakEventManager), только не сказать что они выглядят удобными :)
К сожалению, Вы ошибаетесь, lock(this) есть и он нужен (в многопоточной среде). Посмотрите на атрибуты акцессоров событий: они отмечены [MethodImpl(MethodImplOptions.Synchronized)], который эквивалентен оборачиванию тела метода в lock(this) { }, однако в C# 4.0 генерируемый код для акцессоров field-like событий изменился, теперь там lock-free реализация подписки/отписки. Не смотря на на то, что делегаты — ref-типы, при подписке два потока могут забрать одну и ту же ссылку, а потом записать свои скомбинированные через Delegate.Combine() делегаты поверх друг друга, поэтому применение += к делегатам не является потокобезопасной операцией.
По поводу C#: если Вы поразмыслите чуток как почему это работает в python, то возможно осознаете, что эта фича хорошо всписывается только в динамические языки ;))) В C# пришлось бы делать медленный вызов через механизм отражения или генерировать много call-site кода ради сомнительной удобности :) Да ещё и обратите внимание, что в python нету перегрузки методов как таковой ;)
Дело в том, что ко-/контравариантность введена на уровне рантайма .NET 4.0, теперь опкоды MSIL, такие как castclass и isinst (операторы as и is в C#) считают, например, что IEnumerable<string> можно скастить в рантайме к IEnumerable<object>.
То есть в .NET 3.5 можно переменной IEnumerable<object> присвоить IEnumerable<string>, но вот xs is IEnumerable<object> (при переменной IEnumerable<string> xs) будет возвращать false.
То есть полного поведения .NET 4.0 при компиляции под .NET 3.5 получить не получится.
Позвольте спросить, а что это такое, «свертка/разаертка ипенованых параметров»?
* Запретить optional parameters для override-методов — почему должна быть нарушена некая «консистентность», чем они хуже невиртуальных методов?
* Требовать в override указывать точно такое же значение — значение по-умолчанию может быть достаточно сложно в записи и требование от юзера копипасты не выглядит верным решением.
* Забирать из метаданных переопределяемого метода значение по умолчанию и запретить задавать другое — возможно это было бы лучшим решением. Но интересно, могут ли быть реально обоснованные причины изменять значение по умолчанию в override?
Не думаю, что это всё вообще будет составлять проблему, так как в C# значительно лучше развит intellisense, который при вызове всегда покажет какое значение реально будет использовано :)))
В рефлекторе видно так:
void Foo([Optional, DefaultParameterValue(true)] bool ensureIsUpToDate)
Имхо тема Rx не раскрыта, если бы сам не поиграл с Rx, то после подкаста желания, наверное, не возникло бы, так как просто не понял бы зачем оно мне надо в real life. Много неточностей, например, IDisposable, возвращаемый при подписке, никоим образом не связан с weak events pattern, это просто способ отписки от observable последовательности и высвобождения ресурсов (и в этом большой бенефит Rx, так как обычно подписываясь лямбдами на события, их потом хрен отпишешь, так как нужен абсолютно тот же экземпляр делегата, а тут лишь .Dispose() дёрнуть надо). Мало сказано про интерфейсы и их контракт, про дуализм с IEnumerable… А вот комбинаторам достаточно внимания им уделили и вцелом хорошо осветили.
Но всё равно вы очень крутые, послушал вас с удовольствием и дальше буду слушать, так держать!