Re[15]: Dart - The worst of both worlds ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.11.11 15:05
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Да да да. Вот я и говорю — все твои логические построения основаны на воплях непонятных личностей.

ГВ>>А сам-то ты "чьих будешь"?
НС>А это неважно. Мои высказывания ты в качестве доказательств не приводил.

И не собираюсь (пока что, во всяком случае). До тех пор, пока ты не убедишь меня в том, что твои высказывания — это что-то, отличное от очередной порции домыслов: "слышал звон, не понял, о чём он". То есть одно из двух: либо твои доводы принимаются наравне с доводами обруганных тобой MVP, либо (если мы отвергаем доводы MVP, поскольку это плохие MVP, негодные) — ты доказываешь, что уж твои-то доводы куда как ближе к реальности. Как ты это докажешь — не знаю. "Чьих ты будешь" — это, разумеется, подначка, на самом деле меня это не волнует.

На данный момент получается один голос НС против давешнего хора MVP и других любителей дотнета.

НС>>>Причем выбираешь ты только те, что доказывают твои теории, что красноречиво говорит об истинных мотивах.

ГВ>>Ad hominem, и как следствие — не имеет никакого значения.
НС>Ой, вот только не строй из себя идеально конструктивного собеседника. Если я начну фиксировать все твои приемчики, на остальное места не останется, бо у тебя их традиционно фантастическое количество.

Да на здоровье, фиксируй. Только на досуге почитай что-нибудь про некорректную аргументацию, а то уже не смешно. Меня-то ты этим не расстроишь, просто лишние буквы тратить надоедает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Dart - The worst of both worlds ?
От: MxMsk Португалия  
Дата: 13.11.11 15:39
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если этот get/set один на все св-ва, а для доступа к конкретному требуется уникальный объект-описатель св-ва, то именно его я и позволил себе так назвать. Иначе бы та фраза была в несколько раз длиннее, хотя все и так поняли, о чем шла речь. Акцессором я считаю так же потому, что эти уникальные объекты доступны публично. Не напомнишь, почему они не остались на уровне protected?

MM>>Никакого троллинга, всё просто, меньше надо тараканов в голове держать.
V>Да уже понял, что придирка к термину... но это вдвойне троллинг, бо казалось, что ты хотел какие-то технические вещи спросить, хотя и сам ответы знаешь...
Давай я оставлю это без обсуждения, чтобы не продолжать тему троллинга. Ты заблуждаешься насчет меня.

MM>>А вот что такое "самоописываемый подход" мне как-то не удалось понять. Перечитываю твои посты по нескольку раз и не могу вычленить, что же это за подход такой, который бы смог обеспечить всю текущую функциональность Dependency Property.

V>Дык, DependencyProperty, в свою очередь, тоже не всю функциональность обеспечивает, а только заложенную в него. Если что-то выходит за рамки, например, транзакционность изменений групп св-в в рамках одного логического события, то как и везде — ручками.
А что, кто-то сказал, что DependencyProperty может всё?

V>Еще немного сбивает с толку несколько плохосвязанных задач:

V>- динамическое расширение набора св-в, дублирует IPropertyProvider, IExpando, а так же динамику 4-го дотнета;
Нет, не дублирует, а предлагает другой способ. Предлагает возможность расширения без затрагивания расширяемого класса.

V>- рефлексия, дублирует встроенную;

Не соглашусь, потому что в XAML вполне можно задавать и не Dependency свойства.

V>- с 0-ля сделали YA диспатчинг, старательно наступив на грабли, которые были побороты еще в ActiveX/DCOM;

Не знаю, что такое "YA диспатчинг". Буду рад, если напишешь в двух словах.

V>Для завязки всей этой функциональности в "единую точку" в WinForms и в WPF есть одноименный объект Binding (связь, связка). Если WinForms сей объект "сам" строится из описаний атрибутов и принятых соглашений, то в WPF мы описываем промежуточную декларативную единицу — DependecyProperty, потеряв легковесность и распределенность подхода ComponentModel (например, в последней можно отфильтровать как сами св-ва для биндинга, так и подкорректировать принадлежащие св-вам аттрибуты, что дает доопределять или переопределять характеристики св-в).

DependencyProperty не для binding-а вводили. Назначение DependencyProperty — обеспечивать выбор эффективного значения в зависимости от ситуации. По дефолту, из стиля, из биндинга, локально, из анимации. Мне думается в этом и проблема, что ты рассматриваешь эту функциональность только в разере binding-а.

MM>>Давай рассмотрим сценарий attached behavior. Есть много разных контролов, переделать которые мы никак не можем. Есть простая задача: например мы хотим сделать простой биндинг к значениям, которые можно получить только в каком-нибудь событии этих контролов. Сейчас такое в WPF делается на ура, минут за 30. Как такое сделать в Windows Forms?

V>В XAML или в коде? Просто в коде "ручками" это на любой технологии за 5 мин делается, через определение интерфейса Model, к которой осуществляется биндинг (в смысле публичного интерфейса некоего типа, не обязательно interface как тип данных). А если речь о XAML, то это уже поддержка декларативности... И не уверен, что оправданная для такой задачи, бо XAML не очень хорошо смотрится в виде "визуального языка программирования". C# удобнее смотрится для порождения абстракций.
Погоди, никакой модели нет. Речь о контролах. Скажем мне понадобилось сделать простую вещь: хочу при возникновении события вызывать команду. В любом контроле, в любом XAML-е, в коде. Хочу дать такую же возможность пользователем моей библиотеки. Эта задача очень просто решается через написание attached behavior (пример). Интересно, как ее "за 5 минут" сделать в Windows Forms?

MM>>Следующий вопрос. У меня есть класс, в нем есть свойство, на изменение которого я хочу реагировать. Оказалось так, что автор класса не озаботился написанием метода OnSomePropertyChanged.

V>Значит, это св-во не предназначено для непосредственного биндинга.
И снова я не о биндинге. Я наследуюсь от чужого контрола и мне требуется среагировать не изменение.

MM>>Что предлагает в этом случае "самоописываемый подход"? Вешать обработчик через AddValueChanged плохо, потому что компонент навечно окажется в списке ссылок статического класса, следовательно никакой сборки мусора.

V>Нет, не поэтому плохо.
V>А потому, что если объект НЕ предоставляет события о внутреннем изменении св-ва, то вешать хук на изменении св-ва извне — это источник популярного бага. Напомню, что бывают св-ва, которые вычисляются при каждом вызове, даже если есть сеттер. В общем, не все св-ва тривиальные, иначе бы не было смысла вводить св-ва взамен публичных полей. Поэтому, зачастую может не быть нотификации, если для вычисления значения св-ва используются внешние опрашиваемые данные, т.е. которые тоже не дают нотификаций. Оставлю за рамками обсуждение кривизны таких решений, но они есть сплошь и рядом в обозреваемых третьесторонних либах. Т.е. при твоей попытке обыграть отсутствие нотификатора в этом случае ты потратишь время на проектирование нетривиального в поиске бага.
Согласен с этим. И всё же, возможность изменять базовые свойства в DependencyProperty сделана лучше. Для регистрации обработчика нам нужен только идентификатор свойства. Не нужно добавлять в базовый класс виртуальные методы, не нужно писать какой-нибудь доп.метод инициализации свойств. Достаточно предоставить идентификатор. Это очень удобно — сам факт того, что идентификатор свойства имеет отражение в коде.

MM>>Хорошо, как будем проверять, какое именно свойство изменилось? Где взять некоторый идентификатор свойства? PropertyDescriptor? Покажи мне PropertyDescriptor в контракте хотя-бы одного контрола Windows Forms.

V>ICustomTypeDescriptor много где.
Хорошо, есть у меня ICustomTypeDescriptor. Как он поможет мне узнать, что за свойство изменилось?

V>Ну и обязательный боксинг значений DependencyProperty тоже как бы намекает, что универсальностью сей подход не страдает, в отличие от ComponentModel, где мы не платим за каждую минимальную операцию только лишь из-за факта использования некоей инфраструктуры. Мне уже подумалось, может оно и правильно, что DependencyObject из WPF завязан сугубо на WPF, что как бы намекает, что не стоит пытаться использовать фреймворк как универсальный общего назначения. В WCF аналогично... на уровне остальных затрат расходы на боксинг не видны под микроскопом... Но это верно лишь в рамках этой задачи, поэтому тамошний брат-близнец DependencyObject тоже доступен лишь в рамках того фреймворка.

Да, применять DependencyObject в отрыве от WPF не стоит. Поэтому зачастую примеры MVVM используют сочетание POCO объектов и INotifyPropertyChanged. Хотя лично я, по прошествии 3 лет использования WPF, уже не считаю это таким уж необходимым. Биндинг двух DependencyObject работает быстрее, чем через INotifyPropertyChanged. DependencyObject более расширяем и лучше адаптирован под написание UI, где в сущности и нужна ViewModel.
Re[26]: Dart - The worst of both worlds ?
От: MxMsk Португалия  
Дата: 13.11.11 15:46
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я имел ввиду не логически, а физически, как данные хранятся. Ну и внешний интерфейс, кстати, соответствует тому, как эти данные хранятся. Понятное дело, в обоих случаях (WPF/ComponentModel), когда контейнер награждает подчиненные объекты динамическими св-вами, он именно от целевых св-в пляшет, которые как бы константны, т.к. известны в compile-time и зашиты жестко в алгоритмы, но итерируется-то при этом по зависимым объектам времени исполнения... ИМХО, в компонентной модели такое отношение участников выражено в интерфейсах и их взаимодействии явно, т.е. прямо отражает происходяще. А в WPF мы получили YA реализацию шаблона "динамического объекта". А это залет, положа руку на... Бо совсем не хочется иметь неконтроллируемую компилятором (т.е. вне системы типов) возможность случайно присвоить не тому объекту значение не того св-ва (и испортить тем самым что-нить). В общем, здравствуй динамика во всей красе. В случае расширения по принципу компонентной модели извне нет никакого способа установить не то св-во не того объекта из-за приватной инкапсуляции всей логики вокруг расширяемых св-в и конкретного списка самих объектов конкретного контейнера.

Строго говоря, просто так не присвоишь. Сейчас компиляция XAML проверяет наличие аксессоров в коде, что превращает "невозможное" присваивание в хак. С другой стороны, присвоить не то свойство — это не так уж и страшно, а вот невозможность расширять поведение стандартных контролов без наследования — фича куда более востребованная.
Re[14]: Dart - The worst of both worlds ?
От: Ночной Смотрящий Россия  
Дата: 13.11.11 16:27
Оценка:
Здравствуйте, vdimas, Вы писали:

НС>>Студия вполне работает и даже неплохо.


V>Ну да, кое-что сугубо узко-нишевое есть.


И что там такого узконишевого? Вполне сложное GUI приложение, демонстрирующее, что технические проблемы решаемы.

V> Как и девелоперская консоль к MS SQL на дотнете...


Девелоперская консоль это та же самая студия. Недевелоперская, кстати, тоже на дотнете.

V>Гораздо важнее, что в оболочке Windows нет WPF


Кому важнее? Мне, к примеру, вобщем то пофигу, я оболочку Windows не разрабатываю.

V>b) оболочка для Висты и Win7 совершенно новая, те была написана с 0-ля


Пруфлинк про написание с нуля.

V>Эти a и b совместно весьма красноречивы.


Ага, они красноречиво говорят, что, пока Синовский рулит виндой, дотнета в винде не будет даже в минимальном количестве. При абсолютно любых технических характеристиках самого дотнета.

НС>>Круть? И где там в Висте WinRT или Metro?


V>Ты ни разу не смотрел на АПИ DUI70.dll?


Смотрел. Ничего общего.

V>>>Платформу .Net всячески рекламировали, в основном путем раздачи обещаний на "будущее". Т.е. пиши код сейчас, а с новой версией фреймворка он волшебныи образом будет работать заметно быстрее.


Ссылки в студию.

V>Это нам "втолковывали" местные MVP


Как это удобно — сослаться на мнение стороннего человека и на основании этого обвинить МС.

НС>>Весь наблюдаемый здесь и сейчас негатив исходит от тех самых людей, которые исходили негативом по тем же поводам прям с первого релиза дотнета.


V>Не совсем...


Совсем. Ну ни одного нового имени в этом топике.

V>Ну реально, я фактически весь фреймворк перерыл рефлектором в свое время... Качество кода — просто безобразное.


Качество кода — очень разное. От посредственного до очень высокого. Как и в абсолютно любой другой платформе.

V>Это всё в совокупности лишь показывает отношение к дотнету внутри самой MS.


Как будто внутри самой МС есть большие библиотеки с существенно лучшим кодом.

V>Ну и напомню о резко изменившемся тренде последних лет.


Ни ты ни ГВ пока что никакого тренда на фактах не продемонстрировали. Все ваши "доказательства" сводятся к крикам неназванных MVP.

НС>>А почему devdiv индусы оккупировали, причем до самого верха, а талантливые разработчики оттуда пачками свалили? Почему Балмер во главе корпа?


V>Компилятор C++ тоже индусы пишут?


Без понятия. Но вполне возможно. Никакого приоритета С++ перед C# внутри dev div нет. Более того, внутри Midori даже для низкоуровневых задач используется некая вариация C#. Но это dev div, Раддер и т.п. А там где прямо или косвенно рулит Синовский, там никакого дотнета ни в каком виде не было и нет. Тенденция со времен отодвигания СОМ от основной компонентной платформы неизменная уже 10 лет.
Re[14]: Синофски
От: Ночной Смотрящий Россия  
Дата: 13.11.11 16:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Как я понял, подразделение Синофски зарабатывает львиную долю денег для MS.

НС>>Это не подразделение Синовского, это подразделение МС. И львиную долю денег оно зарабатывало и до его прихода.

ГВ>Что вижу — о том пою.


Ну то есть в очередной раз избирательное зрение. Понятно.

НС>>И чего? Истериков, если поискать, везде хватает.


ГВ>Ничего. Ты сам говорил пару постингов назад:

НС>>Это да — с каждой новой виндой истерика "любителей" дотнета возрождается аки феникс.

Я вот тебе и показываю, что истерят вовсе даже не "любители" (сиречь — хулители) дотнета, а люди, вполне даже заинтересованные в его развитии.


Ну да, попадаются и такие.

ГВ> Кто они такие на самом деле — мне до лампочки.


Вот я и говорю — ты крайне неразборчив в источниках информации.

ГВ>А вот теперь можно вопрос: на каком основании я должен верить тебе?


А я тебя разве к этому призываю? Верить надо не мне, а наблюдаемым объективным фактам.
Re[15]: Dart - The worst of both worlds ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.11.11 16:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Причем выбираешь ты только те, что доказывают твои теории, что красноречиво говорит об истинных мотивах.

ГВ>>Ad hominem, и как следствие — не имеет никакого значения.
НС>Ой, вот только не строй из себя идеально конструктивного собеседника. Если я начну фиксировать все твои приемчики, на остальное места не останется, бо у тебя их традиционно фантастическое количество.

К стыду своему, не отметил один любопытный момент. Ты здесь по сути говоришь, что если я указываю на некорректность довода, обращённого в свой адрес, то этим пытаюсь в некотором смысле "обелить себя" ("строить идеально конструктивного собеседника"). Так вот, ты заблуждаешься. Констатация некорректности довода означает ровно то, что она означает в буквальном смысле. А всё остальное — это только твои личные индукции.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Синофски
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.11.11 16:48
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>>>>Как я понял, подразделение Синофски зарабатывает львиную долю денег для MS.

НС>>>Это не подразделение Синовского, это подразделение МС. И львиную долю денег оно зарабатывало и до его прихода.
ГВ>>Что вижу — о том пою.
НС>Ну то есть в очередной раз избирательное зрение. Понятно.

Сколько времени Синофски возглавляет это подразделение? AFAIK — с 2008-го. Не так уж мало. Продажи при этом, заметь, не упали, а вполне себе возросли. Ну нет, можно, конечно, рассматривать руководителя отдельно, а успехи подразделения отдельно, но это, по-моему, слишком сильное допущение.

НС>>>И чего? Истериков, если поискать, везде хватает.

ГВ>>Ничего. Ты сам говорил пару постингов назад:

НС>>Это да — с каждой новой виндой истерика "любителей" дотнета возрождается аки феникс.

Я вот тебе и показываю, что истерят вовсе даже не "любители" (сиречь — хулители) дотнета, а люди, вполне даже заинтересованные в его развитии.

НС>Ну да, попадаются и такие.

Да их, похоже, нынче большинство.

ГВ>> Кто они такие на самом деле — мне до лампочки.

НС>Вот я и говорю — ты крайне неразборчив в источниках информации.

Mary-Jo Foley пойдёт в качестве источника?

ГВ>>А вот теперь можно вопрос: на каком основании я должен верить тебе?

НС>А я тебя разве к этому призываю? Верить надо не мне, а наблюдаемым объективным фактам.

Дык. Я как раз про сумму фактов и говорю, включая в эту сумму высказывания и MVP, и Mary-Jo. И потом, извини, не ты ли сам стал рассказывать о "реальной картине" внутренних разборок в MS? Если ты не считаешь, что тебе при этом надо верить, то... Что-то путаница какая-то получается, не находишь?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Dart - The worst of both worlds ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.11.11 17:11
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Студия вполне работает и даже неплохо.

V>>Ну да, кое-что сугубо узко-нишевое есть.
НС>И что там такого узконишевого? Вполне сложное GUI приложение, демонстрирующее, что технические проблемы решаемы.

Восхитительный довод: сначала создать проблему, а потом показать, что её можно решить. Так и хочется сказать: а нафига козе баян?

V>>Гораздо важнее, что в оболочке Windows нет WPF

НС>Кому важнее? Мне, к примеру, вобщем то пофигу, я оболочку Windows не разрабатываю.

Важнее для оценки отношения к дотнету внутри самой MS.

V>>Эти a и b совместно весьма красноречивы.

НС>Ага, они красноречиво говорят, что, пока Синовский рулит виндой, дотнета в винде не будет даже в минимальном количестве. При абсолютно любых технических характеристиках самого дотнета.

То есть Синофски отказывается создавать себе проблемы, чтобы потом с честью их решить. От, негодяй!

V>>Это нам "втолковывали" местные MVP

НС>Как это удобно — сослаться на мнение стороннего человека и на основании этого обвинить МС.

Эти сторонние люди не раз ссылались на высказывания "самих-самих", на доклады и т.п. Так что, не надо всё сводить к одним лишь MVP.

V>>Ну и напомню о резко изменившемся тренде последних лет.

НС>Ни ты ни ГВ пока что никакого тренда на фактах не продемонстрировали. Все ваши "доказательства" сводятся к крикам неназванных MVP.

Сходи в гугль с ключевым словом "c++ renaissance". Будет тебе и тренд, и тенденция.

НС>>>А почему devdiv индусы оккупировали, причем до самого верха, а талантливые разработчики оттуда пачками свалили? Почему Балмер во главе корпа?

V>>Компилятор C++ тоже индусы пишут?

НС>Без понятия. Но вполне возможно. Никакого приоритета С++ перед C# внутри dev div нет. Более того, внутри Midori даже для низкоуровневых задач используется некая вариация C#. Но это dev div, Раддер и т.п. А там где прямо или косвенно рулит Синовский, там никакого дотнета ни в каком виде не было и нет. Тенденция со времен отодвигания СОМ от основной компонентной платформы неизменная уже 10 лет.


Из того, что ты уже наговорил недвусмысленно следует, что действия Синофски весьма далеки от идиотизма и какого-то нелепого политиканства. Они гораздо ближе к голому рационализму. Пока что, во всяком случае, получается так.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Источники-2003
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.11.11 03:38
Оценка: 18 (1)
Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>> Кто они такие на самом деле — мне до лампочки.


НС>Вот я и говорю — ты крайне неразборчив в источниках информации.


Был далёкий 2003-й год. Некто Front написал: http://www.rsdn.ru/forum/philosophy/1779973.1.aspx
Автор: Front
Дата: 14.03.06


А сослался он не на что-нибудь, а прямо таки на Ричарда Грэймса, который немало пишет про COM, .Net и одновременно является... MVP.

И это самый Ричард... Предоставим слово ему самому, вернее, его источникам:

John Montgomery, Director of Product Management said the following in 2003:

Put another way, at PDC 2000, Microsoft debuted the .NET Framework, which introduced a new managed programming model on top of our existing Windows operating systems. With Longhorn and WinFX, we're keeping that managed programming model while building new core parts of the OS, such as moving to the Avalon subsystem next to GDI and User.

Michael Wallent, general manager of the Avalon team said in 2003 (on the .NET Show):

One of the most important things when you think about Longhorn is, it's not just another operating system release like Windows XP or Windows 2000. We think about it more like a wave, and the wave is really made up of more than just any one particular thing. Think about the wave being built upon a foundation of a new platform investment that we've made across the board, built on top of the .NET foundation. And then with Longhorn there'll be client releases and a server release.


Неплохо, правда? И источниками были вовсе даже не пешки, и не сами MVP это всё придумывали. Кстати, сам-то Ричард в конце статьи, мягко говоря, недоумевает по поводу расхождения обещаний MS с реальностью. Это, обращаю твоё внимание, 2003-й год, когда "злостный враг .Net" Стивен Синофски ещё возглавлял Office Product Unit (а вот поди ж ты, какие интриги строил! ).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Dart - The worst of both worlds ?
От: vdimas Россия  
Дата: 14.11.11 10:01
Оценка:
Здравствуйте, MxMsk, Вы писали:

MM>Строго говоря, просто так не присвоишь. Сейчас компиляция XAML проверяет наличие аксессоров в коде, что превращает "невозможное" присваивание в хак.


А при чем тут XAML? Считай XAML как бонус, дающий возможность пользоваться такой фигней, как дизайнер форм. В первую очередь есть некое АПИ библиотеки, а из XAML оно доступно постольку-поскольку. Например, по опыту WinForms далеко не всегда получалось воспльзоваться дизайнером, иногда приходилось делать ГУИ ручками в рантайм, в зависимости от количества и вида данных. Понятно, что в WPF для этого есть шаблоны данных, но у них тоже есть свои ограничения: например, сложно будет на одной странице использовать разные шаблоны для одних и тех же типов данных, придется изворачиваться в исходной модели данных, чтобы вписаться в предоставляемые ср-ва XAML... Или же не изворачиваться с моделью, а построить ручками...


MM>С другой стороны, присвоить не то свойство — это не так уж и страшно,


Если это св-во не использовалось другим каким-нить компонентом, то это всего один баг (потеря значения), а если мы что-то кому-то испортили, то это уже два бага в одном.


MM>а вот невозможность расширять поведение стандартных контролов без наследования — фича куда более востребованная.


В WinForms мне было удобно использоваться такую вещь, как событийные аспекты — это маленькие объекты, которые подписываются на малое кол-во событий контрола, и что-то в ответ на эти события делают прямо с контролом: где-то подрисовывают, где-то устанавливают какие-то св-ва и т.д. Имея некий готовый список таких аспектов, я потом нужные навешивал на контролы, т.е. каждый контрол как виноградная гроздь этими аспектами был увешан, и во многих случаях получалось без наследования. Эта идея была подсказана теми самыми "расширителями", например ToolTip, который правильней было бы назвать ToolTipProvider. Отличие лишь в том, что такие провайдеры цепляются ко всем поддерживаемым типам контролов в контейнере, а аспекты навешивались адресно нужным контролам. В ComponentModel и WinForms подписаться на любое изменение св-ва довольно просто и очевидно, т.к. все события-нотификаторы наружу, для WPF тут нужен хелпер, для подписи к нотификациям, т.к. события об изменении св-в наружу не торчат.
Re[27]: Dart - The worst of both worlds ?
От: vdimas Россия  
Дата: 14.11.11 11:05
Оценка:
Здравствуйте, MxMsk, Вы писали:

Хотелось бы таки от гуру WPF услышать мнение насчет:

Не напомнишь, почему они не остались на уровне protected?


А то противоречие... GetValue/SetValue идет как protected, а ключ у нас public.


V>>Еще немного сбивает с толку несколько плохосвязанных задач:

V>>- динамическое расширение набора св-в, дублирует IPropertyProvider, IExpando, а так же динамику 4-го дотнета;
MM>Нет, не дублирует, а предлагает другой способ. Предлагает возможность расширения без затрагивания расширяемого класса.

Этот класс уже "затронут" тем, что должен быть наследован от DependencyObject.

V>>- рефлексия, дублирует встроенную;

MM>Не соглашусь, потому что в XAML вполне можно задавать и не Dependency свойства.

Да, но в первых бетах нельзя было, а потом в WPF перенесли ту же логику из компонентного подхода, поэтому для источников данных WPF в итоге полностью поддерживает соглашения компонентного подхода, т.е. покрывает обе технологии (со стороны источника данных).

V>>- с 0-ля сделали YA диспатчинг, старательно наступив на грабли, которые были побороты еще в ActiveX/DCOM;

MM>Не знаю, что такое "YA диспатчинг". Буду рад, если напишешь в двух словах.

Строго говоря, роутинг + диспатчинг (т.к. события могут идти из другого потока или даже процесса, как в ActiveX out of proc серверах, поэтому к роутингу нужен диспатчинг) — это распространение событий в иерархической системе ГУИ. Активным может быть один элемент, но событие может быть предназначено не ему, а его либо паренту, либо его подчиненному выбранному элементу/элементам. Фишка в том, что "выбранный" и "в фокусе" — это разные вещи. Задача диспатчинга доставить событие заинтересованному объекту. Задача непростая, тут легко зациклиться или наоборот, пропустиь одну из веток графа. В ActiveX получило развитие OnCommand из MFC, где "правила игры" довольно-таки жесткие и клиенту библиотеки трудно что-либо сломать, а WPF, сколько раз с диспатчингом и триггерами игрался, столько раз ломал систему буквально в первые 15 мин. Вот эта легкость что-нить сломать в распространении событий меня покоробила больше всего когда-то. Причем, несколько раз получалось что-то сломать даже не трогая сам диспатчинг и триггера, а просто комбинируя третьесторонние контролы в разных комбинациях вложенности друг в друга. Когда-то я это уже писал тебе...


V>>Для завязки всей этой функциональности в "единую точку" в WinForms и в WPF есть одноименный объект Binding (связь, связка). Если WinForms сей объект "сам" строится из описаний атрибутов и принятых соглашений, то в WPF мы описываем промежуточную декларативную единицу — DependecyProperty, потеряв легковесность и распределенность подхода ComponentModel (например, в последней можно отфильтровать как сами св-ва для биндинга, так и подкорректировать принадлежащие св-вам аттрибуты, что дает доопределять или переопределять характеристики св-в).

MM>DependencyProperty не для binding-а вводили. Назначение DependencyProperty — обеспечивать выбор эффективного значения в зависимости от ситуации. По дефолту, из стиля, из биндинга, локально, из анимации. Мне думается в этом и проблема, что ты рассматриваешь эту функциональность только в разере binding-а.

Справедливости ради, в WinForms похожая схема (посмотри рефлектором), т.е. не установленные явно значения не требуют памяти для хранения, а берутся дефолтные или из парента, но! эта схема там выполняет только эту задачу. Я не зря обращаю внимание, что на DependencyProperty было свалено несколько ортогональных задач, т.е. приписывать какую-то одну "важную" задачу им не стоит.


MM>>>Давай рассмотрим сценарий attached behavior. Есть много разных контролов, переделать которые мы никак не можем. Есть простая задача: например мы хотим сделать простой биндинг к значениям, которые можно получить только в каком-нибудь событии этих контролов. Сейчас такое в WPF делается на ура, минут за 30. Как такое сделать в Windows Forms?

V>>В XAML или в коде? Просто в коде "ручками" это на любой технологии за 5 мин делается, через определение интерфейса Model, к которой осуществляется биндинг (в смысле публичного интерфейса некоего типа, не обязательно interface как тип данных). А если речь о XAML, то это уже поддержка декларативности... И не уверен, что оправданная для такой задачи, бо XAML не очень хорошо смотрится в виде "визуального языка программирования". C# удобнее смотрится для порождения абстракций.
MM>Погоди, никакой модели нет. Речь о контролах. Скажем мне понадобилось сделать простую вещь: хочу при возникновении события вызывать команду. В любом контроле, в любом XAML-е, в коде. Хочу дать такую же возможность пользователем моей библиотеки. Эта задача очень просто решается через написание attached behavior (пример). Интересно, как ее "за 5 минут" сделать в Windows Forms?

Ааа... дык я тебе уже писал год назад:

Пример заключется в том, что PretranslateMessage() хоть и беднее в разы роутинга WPF, но так же дает меньше степеней свободы для глупых ошибок. По крайней мере свой командный фреймворк с поддержкой визуального дизайн-тайм для WinForms был написан когда-то за вечер, в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься.

Если ВДРУГ тебе по работе потребуется сделать что-то на ВинФормс и захочется любимую парадигму Command попользовать, обращайся, вышлю, там совсем чуть-чуть кода.
Выглядит это так в дизайнере при редактировании кнопки или меню:


Событие используется только Click, но несложно добавить так же выбор события, на которое реагировать. А свое мнение, насчет легкости добавки подобных примитивных вещей в WinForms и в WPF уже высказывал там же: http://www.rsdn.ru/forum/flame.comp/4030351.1.aspx
Автор: vdimas
Дата: 09.11.10


Т.е. для меня сей вывод из WPF печален: предоставляя больше возможностей и реализованных сценариев "из коробки", сложно что-либо добавлять свое, не поддерживаемое коробочной функциональностью. Идеология ComponentModel ровно наоборот — даны простые правила игры, и можно навертеть что угодно относительно дешево.


MM>>>Следующий вопрос. У меня есть класс, в нем есть свойство, на изменение которого я хочу реагировать. Оказалось так, что автор класса не озаботился написанием метода OnSomePropertyChanged.

V>>Значит, это св-во не предназначено для непосредственного биндинга.
MM>И снова я не о биндинге. Я наследуюсь от чужого контрола и мне требуется среагировать не изменение.

Те же яйца в профиль: тогда должна быть доступная для переопределения OnXXXPropertyChanged, если это не DependencyObject. А если ее нет, то св-во не предназначено для реагирования для его изменения, оно, значит, частично или полностью вычисляемое.

V>>А потому, что если объект НЕ предоставляет события о внутреннем изменении св-ва, то вешать хук на изменении св-ва извне — это источник популярного бага. Напомню, что бывают св-ва, которые вычисляются при каждом вызове, даже если есть сеттер. В общем, не все св-ва тривиальные, иначе бы не было смысла вводить св-ва взамен публичных полей. Поэтому, зачастую может не быть нотификации, если для вычисления значения св-ва используются внешние опрашиваемые данные, т.е. которые тоже не дают нотификаций. Оставлю за рамками обсуждение кривизны таких решений, но они есть сплошь и рядом в обозреваемых третьесторонних либах. Т.е. при твоей попытке обыграть отсутствие нотификатора в этом случае ты потратишь время на проектирование нетривиального в поиске бага.

MM>Согласен с этим. И всё же, возможность изменять базовые свойства в DependencyProperty сделана лучше. Для регистрации обработчика нам нужен только идентификатор свойства. Не нужно добавлять в базовый класс виртуальные методы, не нужно писать какой-нибудь доп.метод инициализации свойств. Достаточно предоставить идентификатор. Это очень удобно — сам факт того, что идентификатор свойства имеет отражение в коде.

INotiryPrpoertyChanged имеет такую же идеологию. Только идентификатор строковый. Я ведь всегда ЗА, когда есть какая-нить полезная функциональность, но против, когда эта функциональность одновременно выступает ограничением. Все, что ты говоришь, могло идти как библиотечная реализация, не накладывающая ограничений на другие объекты, т.е. в духе ComponentModel аспекты надо было разнести по интерфейсам, завязавшись только на них, чтобы где что-то надо сделать по-своему — не было проблем... А теперь, я вижу СКОЛЬКО вопросов и какие по характеру возникают по WPF в разделе Net GUI форума и делаю вывод, что эта библиотека не очень удобна разработчикам.


MM>>>Хорошо, как будем проверять, какое именно свойство изменилось? Где взять некоторый идентификатор свойства? PropertyDescriptor? Покажи мне PropertyDescriptor в контракте хотя-бы одного контрола Windows Forms.

V>>ICustomTypeDescriptor много где.
MM>Хорошо, есть у меня ICustomTypeDescriptor. Как он поможет мне узнать, что за свойство изменилось?

Это уже второй вопрос, не к контракту, а к функциональности. А функциональность — это библиотечное дело.


MM>Биндинг двух DependencyObject работает быстрее, чем через INotifyPropertyChanged.


INotifyPropertyChanged — лишь один из механизмов. Но твой биндинг не может работать быстрее, чем приятно в соглашениях ComponentModel насчет event XXXPropertychanged. Да и каждое обращение к св-ву — это обращение к dictionary, где уж тут быстрее?

MM>DependencyObject более расширяем и лучше адаптирован под написание UI, где в сущности и нужна ViewModel.


Скорее не так. Он оправдан там, где св-в у объектов много, а реально выставляется малое их кол-во. Тогда вся система вокруг дефолтных пропертей или из стилей показывает весь свой профит. Но про стили мы тоже как-то уже проходились, если ты помнишь то обсуждение насчет сравнения с возможностями системы стилей CSS... Неохота повторяться, но вывод такой, что стили в WPF — суть набор императивных действий, а не каскадное декларативное описание, с тосно таким же профитом насчет каскадности описаний дефолтных значений св-в как для HTML. Без этой вот каскадности идея дефолтных значений не доведена до ума.
Re[28]: Dart - The worst of both worlds ?
От: MxMsk Португалия  
Дата: 14.11.11 11:18
Оценка:
Здравствуйте, vdimas, Вы писали:

MM>>Строго говоря, просто так не присвоишь. Сейчас компиляция XAML проверяет наличие аксессоров в коде, что превращает "невозможное" присваивание в хак.

V>А при чем тут XAML? Считай XAML как бонус, дающий возможность пользоваться такой фигней, как дизайнер форм. В первую очередь есть некое АПИ библиотеки, а из XAML оно доступно постольку-поскольку. Например, по опыту WinForms далеко не всегда получалось воспльзоваться дизайнером, иногда приходилось делать ГУИ ручками в рантайм, в зависимости от количества и вида данных. Понятно, что в WPF для этого есть шаблоны данных, но у них тоже есть свои ограничения: например, сложно будет на одной странице использовать разные шаблоны для одних и тех же типов данных, придется изворачиваться в исходной модели данных, чтобы вписаться в предоставляемые ср-ва XAML... Или же не изворачиваться с моделью, а построить ручками...
Если речь не о XAML, то не стоит волноваться. Безусловно, я могу любому компоненту написать SetValue с указанием "левого" свойства. Это такая же проблема, как while(true) — исключительно на сознательности программиста. Принято создавать CLR-ное свойство вокруг SetValue/GetValue, с которым большинство и работает. Непосредственно SetValue и GetValue используют для attached свойств, а у них от природы ложиться туда, где их не ждут.

MM>>С другой стороны, присвоить не то свойство — это не так уж и страшно,

V>Если это св-во не использовалось другим каким-нить компонентом, то это всего один баг (потеря значения), а если мы что-то кому-то испортили, то это уже два бага в одном.
От этого не защитят и обычные свойства.

MM>>а вот невозможность расширять поведение стандартных контролов без наследования — фича куда более востребованная.

V>В WinForms мне было удобно использоваться такую вещь, как событийные аспекты — это маленькие объекты, которые подписываются на малое кол-во событий контрола, и что-то в ответ на эти события делают прямо с контролом: где-то подрисовывают, где-то устанавливают какие-то св-ва и т.д. Имея некий готовый список таких аспектов, я потом нужные навешивал на контролы, т.е. каждый контрол как виноградная гроздь этими аспектами был увешан, и во многих случаях получалось без наследования. Эта идея была подсказана теми самыми "расширителями", например ToolTip, который правильней было бы назвать ToolTipProvider. Отличие лишь в том, что такие провайдеры цепляются ко всем поддерживаемым типам контролов в контейнере, а аспекты навешивались адресно нужным контролам. В ComponentModel и WinForms подписаться на любое изменение св-ва довольно просто и очевидно, т.к. все события-нотификаторы наружу, для WPF тут нужен хелпер, для подписи к нотификациям, т.к. события об изменении св-в наружу не торчат.
Вообще то нет. В WPF контролы также имеет нотификации об изменениях свойств, если это предусмотрел автор. Также как и в WinForms. Если не хватит, можно прицепить Binding.
Re[15]: Dart - The worst of both worlds ?
От: vdimas Россия  
Дата: 14.11.11 12:05
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Студия вполне работает и даже неплохо.


V>>Ну да, кое-что сугубо узко-нишевое есть.


НС>И что там такого узконишевого? Вполне сложное GUI приложение, демонстрирующее, что технические проблемы решаемы.


Некритично время запуска приложения. Позволю себе считать это очень уж нишевым допущением на десктопе.


V>>b) оболочка для Висты и Win7 совершенно новая, те была написана с 0-ля


НС>Пруфлинк про написание с нуля.


Пруфилинк заключается в сильно обновленном Shell API, а так же в том, что десктопное окно и окна эксплорера, а так же фреймы обычных окон рисуются явно на DirectX Surface, бо такую отзывчивость тех же операций на классическом GDI не получить. Так же отсылаю к значительным (я бы сказал, ломающим и революционным) изменениям в DirectX 10.0 (в сравнении со всеми остальными изменениями версий от 5 до 9), специально для Висты. ИМХО, там резко улучшилось взаимодействие HDC и DirectX Surface, т.е. стало удобней из всех поз получать первое из второго, т.е. рисовать легаси-кодом прямо на DirectX поверхности. Отличия версии 11 (для Win7) от 10 опять незначительные, т.е. не ломают сам принцип использования DirectX, как это было при переходе 9 -> 10.


V>>Эти a и b совместно весьма красноречивы.


НС>Ага, они красноречиво говорят, что, пока Синовский рулит виндой, дотнета в винде не будет даже в минимальном количестве. При абсолютно любых технических характеристиках самого дотнета.


Плохо верится в эту самую "абсолютность". Если характеристики начнут не уступать тому, что делает современный их компилятор С++, ситуация поменяется оч быстро. Вряд ли на таком уровне сидят совсем уж дураки. А пока я вижу, что они борятся за эффективность даже в нейтиве в новых версиях win8, известная ссылка его доклада насчет технологий уплотнения памяти пробегала тут многократно.


V>>Ты ни разу не смотрел на АПИ DUI70.dll?


НС>Смотрел. Ничего общего.


Я вижу практически такое же АПИ основных контролов. Хотя формат XAML отличается от формата DirectUI XML, но это разница в парсере другого XAML, т.е. не такая уж принципиальная, в сравнении с трудоемкостью разработки самой windowless GUI библиотеки.


V>>>>Платформу .Net всячески рекламировали, в основном путем раздачи обещаний на "будущее". Т.е. пиши код сейчас, а с новой версией фреймворка он волшебныи образом будет работать заметно быстрее.


НС>Ссылки в студию.


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


НС>Как это удобно — сослаться на мнение стороннего человека и на основании этого обвинить МС.


В принципе да... это касается конкретно форумов этого сайта больше, чем MS. Слишком уж высокий был градус со стороны рекламистов дотнета когда-то... Но мы же на этом же форуме сейчас продолжаем, верно?


V>>Это всё в совокупности лишь показывает отношение к дотнету внутри самой MS.


НС>Как будто внутри самой МС есть большие библиотеки с существенно лучшим кодом.


Хотя бы ATL, весьма грамотная разработка. Думаю и MFC могли бы переделать, если бы не эта вся та же самая проклятая совместимость с версиями, разработанными еще на первых компиляторах С++.


V>>Ну и напомню о резко изменившемся тренде последних лет.


НС>Ни ты ни ГВ пока что никакого тренда на фактах не продемонстрировали. Все ваши "доказательства" сводятся к крикам неназванных MVP.


Ориентация Win8 на широкий класс устройств — тоже демонстрация этого тренда. Масштабируемость начинает быть требованием по-умолчанию. А дотнет этим не страдает, он плохо работает на маленьких устройствах, и не умеет выжимать все из больших (где десятки ядер).

НС>>>А почему devdiv индусы оккупировали, причем до самого верха, а талантливые разработчики оттуда пачками свалили? Почему Балмер во главе корпа?


V>>Компилятор C++ тоже индусы пишут?


НС>Без понятия. Но вполне возможно. Никакого приоритета С++ перед C# внутри dev div нет.


Не знаю, я много исследовал примерно 3 года назад бинарный код, который после JIT или после ngen, с тем, что генерит на аналогичное компилятор С++, чтобы понять разницу в быстродействии в 3-5 раз для целей обработки сигналов... Ну там просто несравнимое генерируемое кач-во кода, поэтому я и уверен, что JIT-подсистеме и ngen-у уделяется внимание, сравнимое с выделяемым компилятору С++.


НС>Более того, внутри Midori даже для низкоуровневых задач используется некая вариация C#.


Мне показалось, что его забросили в пользу BarrelFish. А последний вообще открыли, что показывает степень коммерческой заинтересованности.


НС>Тенденция со времен отодвигания СОМ от основной компонентной платформы неизменная уже 10 лет.


Дотнет удобен, но его характеристики недалеко ушли от явовских. ИМХО, до тех пор, пока будет целью ставится конкуренция с явой — ничего не изменится. Мне, как инженеру, совершенно непонятно, чем оптимизация на этапе ngen должна отличаться от оптимизаци нативного приложения. Я понимаю, требования GC и прочего, но я специально исследовал случаи, когда на стеке располагаю исключительно свои value-типы, представляющие из себя состояния фильтров сигналов, т.е не подключаю ничего такого, чтобы бы требовало специального обсуживания фреймов стека для целей GC — и не вижу множества возможных оптимизаций в сравнении с кодом от компилятора С++.
Re[29]: Dart - The worst of both worlds ?
От: vdimas Россия  
Дата: 14.11.11 12:18
Оценка:
Здравствуйте, MxMsk, Вы писали:

MM>>>С другой стороны, присвоить не то свойство — это не так уж и страшно,

V>>Если это св-во не использовалось другим каким-нить компонентом, то это всего один баг (потеря значения), а если мы что-то кому-то испортили, то это уже два бага в одном.
MM>От этого не защитят и обычные свойства.

Ты не можешь у обычных св-в вызвать несуществующее св-во или испортить расширяемое св-во некоторого компонента-расширителя.
Re[28]: Dart - The worst of both worlds ?
От: MxMsk Португалия  
Дата: 14.11.11 13:06
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Хотелось бы таки от гуру WPF услышать мнение насчет:

V>Не напомнишь, почему они не остались на уровне protected?
V>А то противоречие... GetValue/SetValue идет как protected, а ключ у нас public.
Мнение, что GetValue и SetValue имеют модификатор доступа public

V>>>Еще немного сбивает с толку несколько плохосвязанных задач:

V>>>- динамическое расширение набора св-в, дублирует IPropertyProvider, IExpando, а так же динамику 4-го дотнета;
MM>>Нет, не дублирует, а предлагает другой способ. Предлагает возможность расширения без затрагивания расширяемого класса.
V>Этот класс уже "затронут" тем, что должен быть наследован от DependencyObject.
Хорошо, предлагает возможность расширения любого класса, унаследованного от DependencyObject, не затрагивая реализацию. Это не отменяет того факта, что здесь не дублирование, а попытка решить задачу более удобным способом, на уровне по понятным причинам не затрагивающим весь .Net.

V>>>- рефлексия, дублирует встроенную;

MM>>Не соглашусь, потому что в XAML вполне можно задавать и не Dependency свойства.
V>Да, но в первых бетах нельзя было, а потом в WPF перенесли ту же логику из компонентного подхода, поэтому для источников данных WPF в итоге полностью поддерживает соглашения компонентного подхода, т.е. покрывает обе технологии (со стороны источника данных).
Получается, что не дублирует, а поддерживает как новый подход, так и старый. Это более чем логично, учитывая, что WPF живет не обособленно, и должна поддерживать и обычные классы .Net.

V>>>- с 0-ля сделали YA диспатчинг, старательно наступив на грабли, которые были побороты еще в ActiveX/DCOM;

MM>>Не знаю, что такое "YA диспатчинг". Буду рад, если напишешь в двух словах.
V>Строго говоря, роутинг + диспатчинг (т.к. события могут идти из другого потока или даже процесса, как в ActiveX out of proc серверах, поэтому к роутингу нужен диспатчинг) — это распространение событий в иерархической системе ГУИ. Активным может быть один элемент, но событие может быть предназначено не ему, а его либо паренту, либо его подчиненному выбранному элементу/элементам. Фишка в том, что "выбранный" и "в фокусе" — это разные вещи. Задача диспатчинга доставить событие заинтересованному объекту. Задача непростая, тут легко зациклиться или наоборот, пропустиь одну из веток графа. В ActiveX получило развитие OnCommand из MFC, где "правила игры" довольно-таки жесткие и клиенту библиотеки трудно что-либо сломать, а WPF, сколько раз с диспатчингом и триггерами игрался, столько раз ломал систему буквально в первые 15 мин. Вот эта легкость что-нить сломать в распространении событий меня покоробила больше всего когда-то. Причем, несколько раз получалось что-то сломать даже не трогая сам диспатчинг и триггера, а просто комбинируя третьесторонние контролы в разных комбинациях вложенности друг в друга. Когда-то я это уже писал тебе...
Я не могу из этого сделать никакого вывода. Кто-то где-то когда-то во что-то игрался — у него не получалось... Ну допустим! А как надо было сделать?

V>>>Для завязки всей этой функциональности в "единую точку" в WinForms и в WPF есть одноименный объект Binding (связь, связка). Если WinForms сей объект "сам" строится из описаний атрибутов и принятых соглашений, то в WPF мы описываем промежуточную декларативную единицу — DependecyProperty, потеряв легковесность и распределенность подхода ComponentModel (например, в последней можно отфильтровать как сами св-ва для биндинга, так и подкорректировать принадлежащие св-вам аттрибуты, что дает доопределять или переопределять характеристики св-в).

MM>>DependencyProperty не для binding-а вводили. Назначение DependencyProperty — обеспечивать выбор эффективного значения в зависимости от ситуации. По дефолту, из стиля, из биндинга, локально, из анимации. Мне думается в этом и проблема, что ты рассматриваешь эту функциональность только в разере binding-а.
V>Справедливости ради, в WinForms похожая схема (посмотри рефлектором), т.е. не установленные явно значения не требуют памяти для хранения, а берутся дефолтные или из парента, но! эта схема там выполняет только эту задачу. Я не зря обращаю внимание, что на DependencyProperty было свалено несколько ортогональных задач, т.е. приписывать какую-то одну "важную" задачу им не стоит.
Не получается. В WinForms нет схемы источников. В WinForms есть хэш-таблица с ключами свойств, сделанная в первую очередь для экономии памяти, потому что свойств дофига, а используются немногие. В случае DependencyProperty экономия просто бонус, есть же у WPF объектов и не dependency свойства. Сочетания разных источников — вот главная цель DependencyProperty. Им это не я приписываю, а авторы книг по WPF и очевидно сама Microsoft

MM>>>>Давай рассмотрим сценарий attached behavior. Есть много разных контролов, переделать которые мы никак не можем. Есть простая задача: например мы хотим сделать простой биндинг к значениям, которые можно получить только в каком-нибудь событии этих контролов. Сейчас такое в WPF делается на ура, минут за 30. Как такое сделать в Windows Forms?

V>>>В XAML или в коде? Просто в коде "ручками" это на любой технологии за 5 мин делается, через определение интерфейса Model, к которой осуществляется биндинг (в смысле публичного интерфейса некоего типа, не обязательно interface как тип данных). А если речь о XAML, то это уже поддержка декларативности... И не уверен, что оправданная для такой задачи, бо XAML не очень хорошо смотрится в виде "визуального языка программирования". C# удобнее смотрится для порождения абстракций.
MM>>Погоди, никакой модели нет. Речь о контролах. Скажем мне понадобилось сделать простую вещь: хочу при возникновении события вызывать команду. В любом контроле, в любом XAML-е, в коде. Хочу дать такую же возможность пользователем моей библиотеки. Эта задача очень просто решается через написание attached behavior (пример). Интересно, как ее "за 5 минут" сделать в Windows Forms?
V>Ааа... дык я тебе уже писал год назад:
Стоило глянуть ссылочку. Там совсем не про команды речь, но зато объясняется суть attached behavior. Команды — это только пример. У меня есть и другие примочки. В чем то это аналогично твоим "событийным аспектам".

V>

V>Пример заключется в том, что PretranslateMessage() хоть и беднее в разы роутинга WPF, но так же дает меньше степеней свободы для глупых ошибок. По крайней мере свой командный фреймворк с поддержкой визуального дизайн-тайм для WinForms был написан когда-то за вечер, в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься.

V>Если ВДРУГ тебе по работе потребуется сделать что-то на ВинФормс и захочется любимую парадигму Command попользовать, обращайся, вышлю, там совсем чуть-чуть кода.
Тяжело с тобой. И откуда столько предвзятости...

V>Событие используется только Click, но несложно добавить так же выбор события, на которое реагировать. А свое мнение, насчет легкости добавки подобных примитивных вещей в WinForms и в WPF уже высказывал там же: http://www.rsdn.ru/forum/flame.comp/4030351.1.aspx
Автор: vdimas
Дата: 09.11.10

Команды в WPF и так есть, незачем их туда добавлять. Вообще да, у меня код для команд писался не один вечер. Только это потому, что он поддерживает передачу параметров через Binding и умеет прикрепляться не только к маршрутизируемым, но и к CLR-событиям. Если сузить задачу до простого вызова команды по клику, то, гм, полчаса, не более. И, кстати, помнится тогда ты писал, что на обдумывание у тебя отнюдь не один вечер ушел. Я разрабатывал эту фичу параллельно с другими задачами и еще возился с некоторыми вверенными мне разработчиками. К тому же, это был мой первый опыт использования FreezableCollection. Теперь гляжу, может суммарно чистого времени там такой же вечер и получился...

V>Т.е. для меня сей вывод из WPF печален: предоставляя больше возможностей и реализованных сценариев "из коробки", сложно что-либо добавлять свое, не поддерживаемое коробочной функциональностью. Идеология ComponentModel ровно наоборот — даны простые правила игры, и можно навертеть что угодно относительно дешево.

Пока что я не увидел никакого преимущества ComponentModel. Пока что я наблюдаю... ох, тут меня снова обвинят в троллинге, но пока что я наблюдаю, ты с WPF знаком далеко не на таком высоком уровне, как сам себе представляешь.

MM>>Согласен с этим. И всё же, возможность изменять базовые свойства в DependencyProperty сделана лучше. Для регистрации обработчика нам нужен только идентификатор свойства. Не нужно добавлять в базовый класс виртуальные методы, не нужно писать какой-нибудь доп.метод инициализации свойств. Достаточно предоставить идентификатор. Это очень удобно — сам факт того, что идентификатор свойства имеет отражение в коде.

V>INotiryPrpoertyChanged имеет такую же идеологию. Только идентификатор строковый. Я ведь всегда ЗА, когда есть какая-нить полезная функциональность, но против, когда эта функциональность одновременно выступает ограничением. Все, что ты говоришь, могло идти как библиотечная реализация, не накладывающая ограничений на другие объекты, т.е. в духе ComponentModel аспекты надо было разнести по интерфейсам, завязавшись только на них, чтобы где что-то надо сделать по-своему — не было проблем... А теперь, я вижу СКОЛЬКО вопросов и какие по характеру возникают по WPF в разделе Net GUI форума и делаю вывод, что эта библиотека не очень удобна разработчикам.
Эка ты скачешь! Вот недавно поднял устаревшую ветку про темы. Не подскажешь, как ComponentModel поможет ее решить? Что до форума .Net GUI в целом, то куча запросов там однотипны и зачастую являются следствием банального незнания технологии. Другая половина — в основном игры разума вокруг MVVM. Реально сложных проблем немного. Да, и еще такой момент: по Windows Forms там запросов никак не меньше

MM>>>>Хорошо, как будем проверять, какое именно свойство изменилось? Где взять некоторый идентификатор свойства? PropertyDescriptor? Покажи мне PropertyDescriptor в контракте хотя-бы одного контрола Windows Forms.

V>>>ICustomTypeDescriptor много где.
MM>>Хорошо, есть у меня ICustomTypeDescriptor. Как он поможет мне узнать, что за свойство изменилось?
V>Это уже второй вопрос, не к контракту, а к функциональности. А функциональность — это библиотечное дело.
Ну, т.е. правильный ответ — никак. Сиди сравнивай строчки, если автор озаботился их написанием и аккуратно следит за переименованием. По факту эта компонентная модель годится только для декларативного биндинга и дизайнера форм. Всё. Использование ее в коде — это полнейший геморрой.

MM>>Биндинг двух DependencyObject работает быстрее, чем через INotifyPropertyChanged.

V>INotifyPropertyChanged — лишь один из механизмов. Но твой биндинг не может работать быстрее, чем приятно в соглашениях ComponentModel насчет event XXXPropertychanged. Да и каждое обращение к св-ву — это обращение к dictionary, где уж тут быстрее?
Хитрость в том, что Binding может работать с DependencyProperty без Reflection.

MM>>DependencyObject более расширяем и лучше адаптирован под написание UI, где в сущности и нужна ViewModel.

V>Скорее не так. Он оправдан там, где св-в у объектов много, а реально выставляется малое их кол-во. Тогда вся система вокруг дефолтных пропертей или из стилей показывает весь свой профит. Но про стили мы тоже как-то уже проходились, если ты помнишь то обсуждение насчет сравнения с возможностями системы стилей CSS... Неохота повторяться, но вывод такой, что стили в WPF — суть набор императивных действий, а не каскадное декларативное описание, с тосно таким же профитом насчет каскадности описаний дефолтных значений св-в как для HTML. Без этой вот каскадности идея дефолтных значений не доведена до ума.
Я говорю о POCO vs DependencyObject в сценариях MVVM, а ты меня уводишь в сторону стилей. Потому я и жалуюсь, что ты пишешь очень много, но контекст постоянно плавающий. Вывести, что реально хочешь сказать сложно, по сто раз читать приходится.
Re[30]: Dart - The worst of both worlds ?
От: MxMsk Португалия  
Дата: 14.11.11 13:08
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты не можешь у обычных св-в вызвать несуществующее св-во или испортить расширяемое св-во некоторого компонента-расширителя.

Переведи. Лучше с примером.
Re[29]: Dart - The worst of both worlds ?
От: vdimas Россия  
Дата: 14.11.11 17:44
Оценка:
Здравствуйте, MxMsk, Вы писали:

V>>Т.е. для меня сей вывод из WPF печален: предоставляя больше возможностей и реализованных сценариев "из коробки", сложно что-либо добавлять свое, не поддерживаемое коробочной функциональностью. Идеология ComponentModel ровно наоборот — даны простые правила игры, и можно навертеть что угодно относительно дешево.

MM>Пока что я не увидел никакого преимущества ComponentModel. Пока что я наблюдаю... ох, тут меня снова обвинят в троллинге, но пока что я наблюдаю, ты с WPF знаком далеко не на таком высоком уровне, как сам себе представляешь.

Да уже и не буду, похоже. Ни разу не смог принять решение, делать на нем какой-нить ГУИ, по целому списку причин. Самая главная причина, конечно же, что итоговая трудоемкость получится больше, для чего-то нетривиального. А все вещи, которые действительно в WPF в шаговой доступности — это произвольное "вкладывание" контролов друг в друга, или параметризируемость стилей отображения, всё это почему-то не столь важно для приложения, где не надо ни контролы друг в друга вставлять, ни стилями играть (максимум палитрой).

Да и способ изучения библиотек у меня свой. Я изучаю что именно позволяют библиотеки, и в какую трудоемкость обходятся моменты, отходящие в сторону от данных из коробки. Например, сравнив реализацию роутинга рефлектором в WPF и свою, причем, срвним очень внимательно (надо же было разобраться, откуда столько кода), я получил представление, во что будут обходиться любые свои навороты. Так же экспериментировал с отображением (не из файла, а из произвольного потока) и захватом видео. Ничего лучше, чем бросить на WPF страницу WinForms контрол в итоге не получилось. И так во всем, что мне реально требовалось... А все эти эффекты вокруг рамок, или списки в виде "каруселей"... ну несерьезно, малость, да еще ценой такой долгой загрузки приложений.

Посмотрим на скорость загрузки нативных Metro-приложений и доступности непосредственного использования любого АПИ, например DirectX. Если не будет проблем ни с первым, ни с вторым, то будет использовано в будущих разработках... Так что, конкретно WPF пролетает в любом случае.

MM>Да, и еще такой момент: по Windows Forms там запросов никак не меньше


Характер вопросов разный. Последний год я не слежу, но до этого, по WinForms если по основам спрашивали совсем новички, а остальные обычно интересовались чем-нить нетривиальным. А по WPF я постоянно вижу вопросы от вовсе не новичков по неким основным вещам WPF, то событие получить не могут, то триггеры не срабатывают. И это уже скоро 7 лет как технология вышла. По WinForms похожий характер вопросов наблюдался максимум первый год.


MM>Ну, т.е. правильный ответ — никак. Сиди сравнивай строчки, если автор озаботился их написанием и аккуратно следит за переименованием. По факту эта компонентная модель годится только для декларативного биндинга и дизайнера форм. Всё. Использование ее в коде — это полнейший геморрой.


Ес-но, компонентная модель нужна для дизайнеров, ибо в коде можно в каждом конкретном месте прикрутить конкретные же соглашения. А в коде ровно наоборот, прикрутить св-во и нотификатор к нему гораздо проще в компонентной модели, чем в WPF. И шанса ошибиться — тоже. Декларация зависимых св-в выглядит страшно.


MM>>>Биндинг двух DependencyObject работает быстрее, чем через INotifyPropertyChanged.

V>>INotifyPropertyChanged — лишь один из механизмов. Но твой биндинг не может работать быстрее, чем приятно в соглашениях ComponentModel насчет event XXXPropertychanged. Да и каждое обращение к св-ву — это обращение к dictionary, где уж тут быстрее?
MM>Хитрость в том, что Binding может работать с DependencyProperty без Reflection.

Угу, а в целом WPF приложения гораздо тормознутее при открытии формы... Откуда же тормоза?

Да и вообще, доступ к св-вам в компонентной модели происходит через виртуальные PropertyDescriptor::GetValue/SetValue, и их переопределяют, если действительно требуется в каком-то моменте быстродействие, например, для источников данных для гридов (см DataRowView). Я это делал автоматически для нужного другого места однажды через библиотеку RFD (она умеет кодогенерить эффективные акцессоры).


MM>Я говорю о POCO vs DependencyObject в сценариях MVVM, а ты меня уводишь в сторону стилей. Потому я и жалуюсь, что ты пишешь очень много, но контекст постоянно плавающий. Вывести, что реально хочешь сказать сложно, по сто раз читать приходится.


Наверно потому, что концепция ViewModel нужна не только в GUI и конкретно паттерне MVVM, а вообще везде, где требуется обеспечить тестопригодность компонент без воссоздания всего остального окружения для тестов. К тому же, ты говоришь, в чем тебе видится профит DependencyObject (без пояснения, т.е. непонятно, с чего бы), а я говорю, в чем это видится мне, с пояснием. Как это стили здесь не при чем? Еще как причем. Для всего остального, типа нотификаций событий и прочей лабуды такое наворачивать не стоило бы, напр. строительство объектов по XAML вполне можно было сделать и на рефлексии. И только именно зависимые данные (зависимые от парентов, стилей, дефолтов, в т.ч. переопределяемых дефолтов, или зависимые от специальных внешних объектов, типа анимаций) и дают какой-то профит этой схемы.
Re[16]: Dart - The worst of both worlds ?
От: Ночной Смотрящий Россия  
Дата: 15.11.11 17:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Восхитительный довод: сначала создать проблему, а потом показать, что её можно решить.


Нет никакой проблемы.

НС>>Кому важнее? Мне, к примеру, вобщем то пофигу, я оболочку Windows не разрабатываю.


ГВ>Важнее для оценки отношения к дотнету внутри самой MS.


Нет никакого единого отношения внутри МС. Есть отношение разных команд и оно разное.

НС>>Ага, они красноречиво говорят, что, пока Синовский рулит виндой, дотнета в винде не будет даже в минимальном количестве. При абсолютно любых технических характеристиках самого дотнета.


ГВ>То есть Синофски отказывается создавать себе проблемы, чтобы потом с честью их решить.


Каие проблемы? Синовского в свое время отодвинули слегонца с его СОМом, поэтому с дотнетом у него личное. К техническим вопросам это отношения не имеет.

НС>>Как это удобно — сослаться на мнение стороннего человека и на основании этого обвинить МС.


ГВ>Эти сторонние люди


Да все уже давно понятно и малоинтересно.

ГВ>Сходи в гугль с ключевым словом "c++ renaissance". Будет тебе и тренд, и тенденция.


Неа, только мечты отдельных товарищей типа тебя.

ГВ>Из того, что ты уже наговорил недвусмысленно следует, что действия Синофски весьма далеки от идиотизма и какого-то нелепого политиканства.


Нет, не следует.
Re[16]: Dart - The worst of both worlds ?
От: Ночной Смотрящий Россия  
Дата: 15.11.11 17:59
Оценка:
Здравствуйте, vdimas, Вы писали:

НС>>И что там такого узконишевого? Вполне сложное GUI приложение, демонстрирующее, что технические проблемы решаемы.


V>Некритично время запуска приложения.


Кому как. И, это, 10 студия с WPF, особенно если мерять вместе с загрузкой солюшена, на моей машине запускается намного быстрее винформсной 9.

V> Позволю себе считать это очень уж нишевым допущением на десктопе.


А я даже и не сомневался.

НС>>Пруфлинк про написание с нуля.


V>Пруфилинк заключается в сильно обновленном Shell API


Ясно, опять пустой треп и фантазии.


НС>>Ага, они красноречиво говорят, что, пока Синовский рулит виндой, дотнета в винде не будет даже в минимальном количестве. При абсолютно любых технических характеристиках самого дотнета.


V>Плохо верится в эту самую "абсолютность"


Ну не верь, мне то что. Доказывать я не буду.

НС>>Смотрел. Ничего общего.


V>Я вижу практически такое же АПИ основных контролов.


Такое же API, ага. Без разделения моделей, шаблонов данных, соответствующего биндинга и кучи других ключевых особенностей WPF.

V> Хотя формат XAML отличается от формата DirectUI XML


Пофиг. Главное, архитектура отличается кардинально.

НС>>Ссылки в студию.


V>Скажем так, этого человека


И ссылок, внезапно, опять нет.

НС>>Как это удобно — сослаться на мнение стороннего человека и на основании этого обвинить МС.


V>В принципе да...


Да я уж вижу. Вы с ГВ даже не стесняетесь своей отборной демагогии. И аргументация у вас как была лет 8 назад, так и осталась. Сорри, не сочти за наезд, но лично я вас за экспертов в новых технологиях воспринимать уже не могу, вы там, 8 лет назад, так и остались.

V>Ориентация Win8 на широкий класс устройств — тоже демонстрация этого тренда


Нет, это демонстрация одной из двух основных стратегий, придуманных лысым. Корни там чисто коммерческие. К примеру, очень хочется подмять под себя хотя бы кусок кабельного ТВ в штатах — это очень вкусный кусок пирога. Планшеты опять же. Рынок растет, МС на нем не видно и в микроскоп, лысый задергался.

V> Масштабируемость начинает быть требованием по-умолчанию. А дотнет этим не страдает, он плохо работает на маленьких устройствах, и не умеет выжимать все из больших (где десятки ядер).


Именно поэтому в ажуре сплошной дотнет Фантазии, фантазии

НС>>Без понятия. Но вполне возможно. Никакого приоритета С++ перед C# внутри dev div нет.


V>Не знаю


Ну а я знаю.

НС>>Более того, внутри Midori даже для низкоуровневых задач используется некая вариация C#.

V>Мне показалось, что его забросили в пользу BarrelFish

Его не могли запросить в его пользу. BarrelFish это MSR, а Midori это корповая разработка. Разные люди, цели и деньги.

V>Дотнет удобен, но его характеристики недалеко ушли от явовских. ИМХО, до тех пор, пока будет целью ставится конкуренция с явой


Про цель — это ты опять сам придумал или пруфлинки есть?

V> Мне, как инженеру, совершенно непонятно, чем оптимизация на этапе ngen должна отличаться


Тебе, как инженеру, непонятно главное — судьба стратегических технологий в МС это не только и не столько технический вопрос, сколько политический. Уже много много раз хорошие продукты дохли из-за ухода ключевых людей, а плохие продукты влачили жалкое существование много много релизов.
Re[16]: Источники-2003
От: Ночной Смотрящий Россия  
Дата: 15.11.11 18:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Неплохо, правда?


Да просто отлично. ГВ наконец добрался до событий 8-милетней давности с Лонгхорном, мир праху его. Глядишь, лет через 8 и до сегодняшних реалий дело дойдет.

ГВ>Это, обращаю твоё внимание, 2003-й год, когда "злостный враг .Net" Стивен Синофски ещё возглавлял Office Product Unit (а вот поди ж ты, какие интриги строил! ).


Вот как раз потому что Синовский до windiv еще не добрался, такое и говорили. Впрочем, бардак с уходом Олчина начался.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.