Pull to refresh

Comments 21

Ух ты, вот это действительно удобное нововведение
UFO landed and left these words here
UFO landed and left these words here
Жаль, что все ексепшены из async метода заворачиваются в System.AggregateException. Усложняется запись catch блока.
UFO landed and left these words here
Ну уже сейчас есть лямбда-выражения, анонимные делегаты, методы-расширения…
Если все это бездумно применять везде, где это возможно, код становится абсолютно нечитаемым.

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

В Java например до сих пор нет событий, вместо этого используется паттерн observer (интерфейс-listener), у каждого своя политика.

DependencyProperty, которые появились в WPF, все еще приходится использовать в соответствии с паттерном для обычных геттеров и сеттеров, может когда-нибудь и их включат в синтаксис C#,
например:

public dependency bool IsActive { get; set; }
Мне кажется, что DependencyProperty никогда не включат в язык, так как изменения для поддержки конкретной прикладной библиотеки ведут в тупик.
C# и .NET не разделимы, C# изначально предназначен конкретно для платформы .NET.
уже сейчас есть синтаксические конструкции типа lock, var и т.п., которые в итоге преобразуются в набор стандартных .NET-конструкций (в случае lock — Monitor.Enter() и Monitor.Exit()).

Если рассматривать базовые классы WPF (DependencyObject, Dependency) не как набор классов для конкретной прикладной библиотеки, а как неотъемлемую часть платформы .NET (также как System.Attribute, System.Enum и т.п.), не вижу ничего преступного в сокращении часто используемых конструкций за счет введения нового ключевого слова в синтаксис C#.

А пока эти DependencyProperty в коде как раз больше напоминают использование паттерна observer вместо событий в Java.
Monitor — часть BCL, а WPF — нет (является нестандартной частью .net framework).
Ну хорошо, убедили.
Тогда хочу, чтобы среда Visual Studio позволяла удобно создавать и управлять этими самими DependencyProperty в коде. XAML-редактор же сделали они, значит можно и в редакторе кода работу со специфичными частями фреймворка сделать более удобными =)

Понятно, что это и сейчас можно сделать самому, написав расширение для Visual Studio, но хочется промышленного решения неудобства.
В отличие от лямбд async — оружие точечного удара, применить его там, где не уместно, сложно.
Кстати, вот пример из Nemerle, где поддержка DependencyProperty реализована макросом:

[DependencyProperty(IsReadOnly)]
internal DependencyProperty2 : string { get { } set { } }
Почему сойдет на нет? Код разбивается на мелкие исполняемые кусочки, у рантайма есть возжность этими кусочками оперировать. Разве что преключения. Но не думаю, что затраты на переключение будут существенней, чем сама операция.
жаль что язык ява так быстро не развивается :(
потому что им идиоты командуют
Идиотизм тут не причем.

Все дело в том, что язык Java это прежде всего кроссплатформенный открытый стандарт, и существует куча реализаций под различные платформы, поддерживаемые различными вендорами. И при выпуске новых версий языка разработчики максимально стараются сохранить обратную совместимость на уровне виртуальной машины, чтобы новые синтаксические конструкции преобразовывались в «старые» в процессе компиляции. В этом случае не нужно каждый раз «допиливать» JVM под каждую из поддерживаемых платформ.

Даже изменение на уровне синтаксиса, которое после компиляции может работать и на «старых» JVM, уже означает необходимость поддержки новых конструкций во всех существующих IDE — NetBeans, Eclipse, IntelliJ IDEA,…

У Microsoft ситуация совершенно иная. У них в руках одна платформа CLR — Windows (ну хорошо, еще на Windows Phone 7), одна официальная среда разработки Visual Studio.

Да, .NET гораздо мобильнее, Java инертнее. Но их вообще нельзя сравнивать напрямую. Java скорее серверная технология, .NET скорее клиентская.
Радикально .net framwork менялся только при смене версий с 1 на 2.
Согласен. А вот синтаксические плюшки появляются от версии к версии (те же лямбда-выражения, анонимные методы, generics, var, extension-методы, dynamic).

В Java этих возможностей гораздо меньше, и появляются они там гораздо медленнее, это факт. Я же хотел указать на то, что это особенность платформы, а не признак их идиотизма.
Не хотите же вы сказать, что MS никогда за 9-10 лет не меняла формат своего байт-кода? Я не в курсе, но в это не верю…
Ничего плохого в том, что нарушится совместимость нет. Пусть успевают за новыми технологиями :)
Да и зачем делать костыли: преобразование новых возможнотсей в старый байт-код? Логично и правильно изменить байт-код.
Да и какие там разные реализации. Есть одна реализация — Sun JDK. Остальное — такаааая хрень… Вот под OpenJDK Intellij IDEA даже не запускается.
Байт-код тут ни при чем, он как раз не менялся минимум лет пять. Большинство нововведений в языке обеспечиваются библиотеками и компилятором, как и в данном случае.
если компилятором, а байт-код у них совместимый, значит от новый версий никто не пострадает и не надо будет ничего переделывать каждый раз при выходе новой версии компилятора
Only those users with full accounts are able to leave comments. Log in, please.