Здравствуйте, Ночной Смотрящий, Вы писали:
V>>результаты которого MS не может применить на собственном десктопе.
НС>Студия вполне работает и даже неплохо.
Ну да, кое-что сугубо узко-нишевое есть. Как и девелоперская консоль к MS SQL на дотнете...
Гораздо важнее, что в оболочке Windows нет WPF, хотя:
a) есть XAML
b) оболочка для Висты и Win7 совершенно новая, те была написана с 0-ля позже выхода WPF.
Эти a и b совместно весьма красноречивы.
V>>MS и пользователями. АПИ W8 ведь не только что родилось, а обкатывалось, начиная с Висты
НС>Круть? И где там в Висте WinRT или Metro?
Ты ни разу не смотрел на АПИ DUI70.dll?
Что есть WinRT? — это пачка довольно-таки независимых библиотек. Та часть, которая обслуживает GUI, давно развивалась и была известна как DirectUI, только не была доступна в публичном виде, хотя через публичный интерфейс IAccessible ковыряется довольно подробно.
V>>Платформу .Net всячески рекламировали, в основном путем раздачи обещаний на "будущее". Т.е. пиши код сейчас, а с новой версией фреймворка он волшебныи образом будет работать заметно быстрее.
НС>МС такого никогда не обещал.
Это нам "втолковывали" местные MVP, которые с семинаров приезжали.
V>> Весь наблюдаемый негатив имеет причиной неисполнение того самого светлого будущего
НС>Весь наблюдаемый здесь и сейчас негатив исходит от тех самых людей, которые исходили негативом по тем же поводам прям с первого релиза дотнета.
Не совсем... Просто если раньше эти же люди выражали лишь скромный скептис по поводу разводимой ньювасюковщины, то теперь они с полным основанием говорят "ага! мы же говорили!".
Ну реально, я фактически весь фреймворк перерыл рефлектором в свое время... Качество кода — просто безобразное. Я бы дал среднему разработчику библиотек фреймворка стаж 3-5 лет, не больше. За дотнетный провайдер MS SQL и парсер его потока надо давать пожизненное отлучение от профессии. А детские баги провайдера соседнего с ним Embedded SQL репортил самолично... там вообще туши свет кидай гранату что творится в коде. И это при том, что если рассматривать MS как одну фирму, а не кучку несвязанных подразделений, то у них есть ОЧЕНЬ эффективный OLEDB провайдер к MS SQL... но нет почему-то преемственности и применения накопленного опыта. Отсюда и скептис.
Это всё в совокупности лишь показывает отношение к дотнету внутри самой MS. Выглядит так, будто это некий имеджевый продукт, с потенциальным прицелом на какое-то отдаленное будущее. Но когда это "будущее" наступит, т.е. когда они возьмутся за эффективность дотнет всерьез — непонятно. Сейчас их, похоже, устраивает ситуация, когда эффективное и отзывчивое пишется на плюсах, а что-нить совершенно некритичное к эффективности — на дотнете.
Ну и напомню о резко изменившемся тренде последних лет. Если в 2002-м все кричали "память и даже лишние тики процессора больше не ресурс"... то теперь, на фоне того, что самый динамично развивающийся сегмент IT — это мобильные и встроенные платформы, толкатели сих лозунгов, мягко говоря, обделались по полной.
НС>А почему devdiv индусы оккупировали, причем до самого верха, а талантливые разработчики оттуда пачками свалили? Почему Балмер во главе корпа?
Здравствуйте, vdimas, Вы писали:
V>Когда-то, когда WPF только вышел, я весьма нелестно отзывался о способе реализации в нем зависимых свойств. Писал, что это грубый отход от возможностей и самого духа дотнета, настоящий шаг назад в сравнении с самоописываемым подходом, принятым в ComponentModel. Ибо ручная разметка акцессоров — это именно что единственный подход в нейтиве, когда необходимо поддержать рефлексию хоть в каком-то виде. (В данном случае, для построения графа объектов по XAML).
Что имеется ввиду под "ручной разметкой акцессоров" и "самоописываемым подходом"?
Здравствуйте, vdimas, Вы писали:
V>Когда-то, когда WPF только вышел, я весьма нелестно отзывался о способе реализации в нем зависимых свойств. Писал, что это грубый отход от возможностей и самого духа дотнета, настоящий шаг назад в сравнении с самоописываемым подходом, принятым в ComponentModel. Ибо ручная разметка акцессоров — это именно что единственный подход в нейтиве, когда необходимо поддержать рефлексию хоть в каком-то виде. (В данном случае, для построения графа объектов по XAML).
Я серьезно спросил. Ибо под "ручной разметкой" можно до фига всего понимать, раз. Не очень то эти "акцессоры" (в том виде, в котором я понял) используются WPF, два.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, vdimas, Вы писали:
V>>Когда-то, когда WPF только вышел, я весьма нелестно отзывался о способе реализации в нем зависимых свойств. Писал, что это грубый отход от возможностей и самого духа дотнета, настоящий шаг назад в сравнении с самоописываемым подходом, принятым в ComponentModel. Ибо ручная разметка акцессоров — это именно что единственный подход в нейтиве, когда необходимо поддержать рефлексию хоть в каком-то виде. (В данном случае, для построения графа объектов по XAML). MM>Я серьезно спросил. Ибо под "ручной разметкой" можно до фига всего понимать, раз. Не очень то эти "акцессоры" (в том виде, в котором я понял) используются WPF, два.
Сорри, но эта тема уже обсуждалась лет 5-6 назад... по-быстрому не нашел, на досуге попробую найти и дать ссылки. Мое ИМХО в том, что описание зависимых св-в — это дублирующая функциональность рефлексии + компонентного подхода. Кроме того, неразбериха с ответственностями, на них были взвалены 3 ортогональные задачи.
Навскидку добавлю... Уши порта с С++ торчат еще в самом сценарии использования зависимых св-в для подчиненных компонент вышестоящего контейнера. Например, стоит задача чтения/записи св-в по составному ключу [компонент, св-во]. Для составных ключей применяют 2 dictionary (вернее, два отображения, не имею ввиду сам конкретно объект Dictionary). И если в компонентной модели цепочка их такова: property->component->value (причем, первый порой вовсе не dictionary, а непосредственное обращение, т.к. property известен в compile-time), то зависимые св-ва используют такую цепочку component->property->value. Это вынуждает накрутить целую инфраструктуру вокруг всего этого, для получения property у компонент, где результатом имеем жесткое ограничение на сами компоненты, которые должны поддерживать инфраструктуру зависимых св-в, т.е. обязательно быть наследником определенного типа! Заметь, в компонентной модели такого ограничения НЕТ, а имеющийся на платформе GC легко разруливает "обратность" этой цепочки словарей/зависимостей для случая компонентной модели. А то, что мы видим в WPF — это как раз удобно для систем, которые вынуждены вручную управлять ресурсами, например COM, чтобы с удалением подчиненного элемента вместе с ним удалились зависимые данные.
Здравствуйте, vdimas, Вы писали:
V>Сорри, но эта тема уже обсуждалась лет 5-6 назад... по-быстрому не нашел, на досуге попробую найти и дать ссылки. Мое ИМХО в том, что описание зависимых св-в — это дублирующая функциональность рефлексии + компонентного подхода. Кроме того, неразбериха с ответственностями, на них были взвалены 3 ортогональные задачи.
V>Навскидку добавлю... Уши порта с С++ торчат еще в самом сценарии использования зависимых св-в для подчиненных компонент вышестоящего контейнера. Например, стоит задача чтения/записи св-в по составному ключу [компонент, св-во]. Для составных ключей применяют 2 dictionary (вернее, два отображения, не имею ввиду сам конкретно объект Dictionary). И если в компонентной модели цепочка их такова: property->component->value (причем, первый порой вовсе не dictionary, а непосредственное обращение, т.к. property известен в compile-time), то зависимые св-ва используют такую цепочку component->property->value. Это вынуждает накрутить целую инфраструктуру вокруг всего этого, для получения property у компонент, где результатом имеем жесткое ограничение на сами компоненты, которые должны поддерживать инфраструктуру зависимых св-в, т.е. обязательно быть наследником определенного типа! Заметь, в компонентной модели такого ограничения НЕТ, а имеющийся на платформе GC легко разруливает "обратность" этой цепочки словарей/зависимостей для случая компонентной модели. А то, что мы видим в WPF — это как раз удобно для систем, которые вынуждены вручную управлять ресурсами, например COM, чтобы с удалением подчиненного элемента вместе с ним удалились зависимые данные.
описание зависимых св-в — это дублирующая функциональность рефлексии + компонентного подхода.
Уже есть в компонентной модели PropertyDescriptor/EventDescriptor с удобным (то бишь абстрактным) получением связанных с ними аттрибутов, чтобы можно было получать эти PropertyInfo как через рефлексию, так и ручками создавать произвольным образом. И так же есть уже отлаженные технология и сценарии использования комовского IExpando или дотнетных ICustomTypeDescriptor/IExtenderProvider. Зачем было городить дубляж ко всему этому, а потом внутрях все-равно обеспечивать интероперабельность со всеми вышеперечисленными артефактами уже имеющейся компонентной модели для целей биндинга (причем, в бете эта интероперабельность хромала на обе ноги, что выглядело странно как минимум)? ИМХО, тут должна была быть серьезная причина, например — минимизация ср-в на разработку, путем порта готовой технологии.
В итоге, читабельность описания 99% обычных св-в компонент явно не соответствует принятому в дотнете отношению многословности и получаемой функциональности... натуральный птичий язык... вместо декларативного одного-двух аттрибутов, как в компонентной модели.
Думаю, нет смысла обсуждать это же повторно, тем более, что с того времени я WPF в руки не брал ни разу... Как посмотрел когда-то внимательно на вышедший третий сервелат, так всё с WPF стало понятно... Могу с удовлетворением отметить, что касаемо роли и степени внимания к WPF оказался тогда полностью прав, хоть оппоненты называли его "mainstream для GUI".
И насчет необходимости непосредственной доступности мультимедиа надесктопе — тоже. Достаточно посмотреть на то, что представляет из себя Metro...
Здравствуйте, vdimas, Вы писали:
V>Уже есть в компонентной модели PropertyDescriptor/EventDescriptor с удобным (то бишь абстрактным) получением связанных с ними аттрибутов, чтобы можно было получать эти PropertyInfo как через рефлексию, так и ручками создавать произвольным образом. И так же есть уже отлаженные технология и сценарии использования комовского IExpando или дотнетных ICustomTypeDescriptor/IExtenderProvider. Зачем было городить дубляж ко всему этому, а потом внутрях все-равно обеспечивать интероперабельность со всеми вышеперечисленными артефактами уже имеющейся компонентной модели для целей биндинга (причем, в бете эта интероперабельность хромала на обе ноги, что выглядело странно как минимум)? ИМХО, тут должна была быть серьезная причина, например — минимизация ср-в на разработку, путем порта готовой технологии.
Послушай, мне нужна вся эта вода. Я прошу дать мне два определения в контексте данного
поста. Первое — "ручная разметка акцессоров". Второе — "самоописываемый подход". Неужели это так сложно?
Я уже как-то сталкивался с подробным тролением с твоей стороны...
Но по делу: очень объемно, если полностью объяснять обе технологии... да и не делают этого здесь никогда, все-таки форум не для домохозяек. Предполагается, что собеседники в курсе о чем идет речь. Если в каждом посте разжевывать все до уровня 0... то обсуждения не получится.
Но чтобы закончить спекуляции, отсылаю для самостоятельного сравнения описания любого популярного св-ва в WinForms, например Background, и аналогичную связку в WPF св-а Background и зависимого св-ва BackgroundProperty, так же сравни способ их использования дизайнерами форм/страниц (конкретней уже некуда, согласись). По результатам сравнения, если что не понятно будет, спрашивай, но уже по-существу. А пока что я не могу предположить, что ты не в курсе, в чем разница описаний св-в там и там, или что не в курсе, как фреймворк формирует список PropertyDescriptor-ов и EventDescriptor-ов для компонентной модели (который способ я и назвал "в духе дотнета") и как это используется для целей визуального дизайна.
Здравствуйте, vdimas, Вы писали:
V>Я уже как-то сталкивался с подробным тролением с твоей стороны...
Да не отмазывайся. Никакого троллинга. Я не хочу спорить. Я прошу, вместо рассуждения о том, как космические корабли бороздят просторы Большого театра, предоставить простое описание двух терминов. Мне не нужны эти огромные посты для девочек, мне не нужна вся эта болтовня в отрыве от конкретики, которая заставляет ретроградов вроде Геннадия (к сожалению) плюсовать твои роскозни. Мне нужны два банальных определения
Здравствуйте, MxMsk, Вы писали:
V>>Я уже как-то сталкивался с подробным тролением с твоей стороны... MM>Да не отмазывайся. Никакого троллинга. Я не хочу спорить. Я прошу, вместо рассуждения о том, как космические корабли бороздят просторы Большого театра, предоставить простое описание двух терминов. Мне не нужны эти огромные посты для девочек, мне не нужна вся эта болтовня в отрыве от конкретики, которая заставляет ретроградов вроде Геннадия (к сожалению) плюсовать твои роскозни. Мне нужны два банальных определения
Во-первых, я отмечаю те посты, которые содержат интересную для меня информацию. Скажи что-нибудь интересное, я и твой пост отмечу.
Во-вторых, благодарю за сочувствие в мой адрес, но ты знаешь, да — я ретроград и ни разу этого не стыжусь. Если я знаю старый, проверенный и хорошо работающий способ решить некоторую задачу — я воспользуюсь им, а не тем, что говорят на десять разных голосов. Поскольку я знаю много способов решения многих задач, и известной палитры мне хватает — так "зачем платить больше"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, MxMsk, Вы писали:
V>>Я уже как-то сталкивался с подробным тролением с твоей стороны... MM>Да не отмазывайся. Никакого троллинга.
Да ну? Тогда дай сначала определение, что значит дать определение двум емким инженерным решениям. Вкратце уже было сказано, даже с примерами. Задавай уточняющие вопросы, что не понятно после отсылки к конкретным примерам и озвучивания ключевых моментов технологий.
MM>Я прошу, вместо рассуждения о том, как космические корабли бороздят просторы Большого театра, предоставить простое описание двух терминов.
Где ты видел термины и космические просторы? Ты всерьез не понял, почему есть предположение насчет порта первых версий с плюсового DirectUI? Или тебя не это интересует, а знакомое слово увидел? Повторюсь, были упомянуты основные характеристики двух разных решений и вкратце их отличия тоже были упомянуты. Спроси конкретно, что ты не понял.
MM>Мне не нужны эти огромные посты для девочек, мне не нужна вся эта болтовня в отрыве от конкретики, которая заставляет ретроградов вроде Геннадия (к сожалению) плюсовать твои роскозни.
Хреновый из тебя тролль, никакого хладнокровия. Это уже нелицеприятная истерика. А ретроградом пока выступаешь ты, регулярно цепляясь за свой островок знаний прикладных аспектов WPF.
MM>Мне нужны два банальных определения
Мало ли кому что нужно... Тебе никто ничего не должен. Хочешь конструктива — изволь проявить конструктив со своей стороны. Спросишь по делу, получишь ответ по делу. Если ты изволил забыться, где находишься, то напомню, что мы инженерные решения обсуждаем, а они терминов обычно не имеют (если не брать устоявшиеся паттерны). Они имеют только словесные и графические описания, степень подробности которых может быть оччень разная. Никак не могу добиться от тебя, какая подробность тебя интересует. Не можешь сформулировать правильно вопросы? Иди тренируйся в нетехническом форуме.
Здравствуйте, vdimas, Вы писали:
V>Хреновый из тебя тролль, никакого хладнокровия. Это уже нелицеприятная истерика. А ретроградом пока выступаешь ты, регулярно цепляясь за свой островок знаний прикладных аспектов WPF.
Хреновый, конечно, ведь я не троллю Ты видимо просто понять не можешь, что мне нет дела до того, откуда у WPF или еще чего растут ноги. Что толку гадать. В итоге мы имеем, "ручная разметка акцессоров" — это статическое поле с DependencyProperty. Спрашивал я об этом потому, что слово "акцессор" в ДотНете обычно означает методы get/set для свойства. Никакого троллинга, всё просто, меньше надо тараканов в голове держать.
А вот что такое "самоописываемый подход" мне как-то не удалось понять. Перечитываю твои посты по нескольку раз и не могу вычленить, что же это за подход такой, который бы смог обеспечить всю текущую функциональность Dependency Property. Давай рассмотрим сценарий attached behavior. Есть много разных контролов, переделать которые мы никак не можем. Есть простая задача: например мы хотим сделать простой биндинг к значениям, которые можно получить только в каком-нибудь событии этих контролов. Сейчас такое в WPF делается на ура, минут за 30. Как такое сделать в Windows Forms?
Следующий вопрос. У меня есть класс, в нем есть свойство, на изменение которого я хочу реагировать. Оказалось так, что автор класса не озаботился написанием метода OnSomePropertyChanged. Что предлагает в этом случае "самоописываемый подход"? Вешать обработчик через AddValueChanged плохо, потому что компонент навечно окажется в списке ссылок статического класса, следовательно никакой сборки мусора. Предусмотреть для всех контролов некий универсальный метод OnPropertyChanged? Хорошо, как будем проверять, какое именно свойство изменилось? Где взять некоторый идентификатор свойства? PropertyDescriptor? Покажи мне PropertyDescriptor в контракте хотя-бы одного контрола Windows Forms.
Здравствуйте, vdimas, Вы писали:
V>Хреновый из тебя тролль, никакого хладнокровия. Это уже нелицеприятная истерика. А ретроградом пока выступаешь ты, регулярно цепляясь за свой островок знаний прикладных аспектов WPF.
С цепочками property->component->value тоже не все так просто. По двум причинам:
1. Инфраструктура нужна в любом случае. От чего не отталкивайся, свойства или компонента, присвоить значение в никуда невозможно.
2. Для DependencyProperty цепочку тоже можно начать от свойств. Ибо мы для свойств задаем обработчик изменений, для свойств задаем корректировки и валидацию. От свойств же мы отталкиваемся, перекрывая поведение для нужных нам компонентов.
Хех, да скорее DependencyProperty в большей степени соответствуют порядку property->component->value. Ну, а DependencyObject можно рассматривать как частный случай компонента, имеющего set-аксессор.
Здравствуйте, Геннадий Васильев, Вы писали:
НС>>Ничуть. Как дотнета в винде не было, так его там и нет. Ничего не изменилось.
ГВ>Ну в этом смысле — безусловно.
А, то есть уже какие то альтернативный смыслы в ход пошли?
НС>>Удивление твое, оно от незнания реальной ситуации. ГВ>Я никак не пойму, что ты называешь реальной ситуацией?
Реальные факты, а не фантастические теории.
ГВ>Ну и плюй на здоровье. Одно другого не отменяет: JCP — всё таки, некоторый формальный фактор, который так или иначе влияет на то, что Oracle сможет вытворять с Java.
Примерчик такого флияния реальный есть?
ГВ>Объясняю — я смотрю на происходящее, как наблюдатель, который просто смотрит и, образно говоря, загибает пальцы — то появилось, это обещалось, то не появилось
Ага, при этом ты совершенно не собираешься различать, от кого обещания исходят. И выбираешь исключительно руководствуясь совпадениями с твоими собственными теориями.
НС>>И это если бы в Метро был SL, тогда действительно можно было бы говорить о каких то ощутимых изменениях. А сейчас, по факту, ничего не изменилось. Скорее наоборот — роль дотнета возросла, так как впервые низкоуровневое API параллельно разрабатывается уже с учетом интересов managed мира.
ГВ>А где там такой учёт?
Здравствуйте, Геннадий Васильев, Вы писали:
НС>>Да да да. Вот я и говорю — все твои логические построения основаны на воплях непонятных личностей.
ГВ>А сам-то ты "чьих будешь"?
А это неважно. Мои высказывания ты в качестве доказательств не приводил.
НС>>Причем выбираешь ты только те, что доказывают твои теории, что красноречиво говорит об истинных мотивах.
ГВ>Ad hominem, и как следствие — не имеет никакого значения.
Ой, вот только не строй из себя идеально конструктивного собеседника. Если я начну фиксировать все твои приемчики, на остальное места не останется, бо у тебя их традиционно фантастическое количество.
Здравствуйте, Геннадий Васильев, Вы писали:
НС>>MVP, они тоже разные бывают.
ГВ>Знаешь ли, звёздочек на них не нарисовано.
Не нарисовано. Но, знаешь ли, у тебя моск есть. И если орел регулярно чушь несет, то неважно, есть у него лычка MVP или нету. А то самые крикливые MVP, если поскрести, на поверку даже основные MVPшные мероприятия ни разу не посещали.
ГВ> Так что, чем один MVP от другого отличается — тайна сия велика есть...
Верится что то с трудом в такое непонимание. Тем же, чем один человек от другого, ваш КО.
ГВ>Негатив, о котором говорит vdimas исходит как раз от дотнетчиков.
Я говорю про этот топик.
НС>>А почему devdiv индусы оккупировали, причем до самого верха, а талантливые разработчики оттуда пачками свалили? Почему Балмер во главе корпа?
ГВ>Так всё таки, какова твоя версия причин победы Синофски над Гатри? Ты не уходи от вопроса.
Не все ли равно? К техническим аспектам это никакого отношения не имеет. Все дело в личностях — Синовский давно и много политикой занимается и весьма поднаторел в этом. А Гатри занимается IT исключительно ради удовлетворения личных интересов, и в политику до сего случая сильно не лез.
Здравствуйте, MxMsk, Вы писали:
V>>Хреновый из тебя тролль, никакого хладнокровия. Это уже нелицеприятная истерика. А ретроградом пока выступаешь ты, регулярно цепляясь за свой островок знаний прикладных аспектов WPF. MM>Хреновый, конечно, ведь я не троллю Ты видимо просто понять не можешь, что мне нет дела до того, откуда у WPF или еще чего растут ноги. Что толку гадать. В итоге мы имеем, "ручная разметка акцессоров" — это статическое поле с DependencyProperty. Спрашивал я об этом потому, что слово "акцессор" в ДотНете обычно означает методы get/set для свойства.
Если этот get/set один на все св-ва, а для доступа к конкретному требуется уникальный объект-описатель св-ва, то именно его я и позволил себе так назвать. Иначе бы та фраза была в несколько раз длиннее, хотя все и так поняли, о чем шла речь. Акцессором я считаю так же потому, что эти уникальные объекты доступны публично. Не напомнишь, почему они не остались на уровне protected?
MM>Никакого троллинга, всё просто, меньше надо тараканов в голове держать.
Да уже понял, что придирка к термину... но это вдвойне троллинг, бо казалось, что ты хотел какие-то технические вещи спросить, хотя и сам ответы знаешь...
MM>А вот что такое "самоописываемый подход" мне как-то не удалось понять. Перечитываю твои посты по нескольку раз и не могу вычленить, что же это за подход такой, который бы смог обеспечить всю текущую функциональность Dependency Property.
Дык, DependencyProperty, в свою очередь, тоже не всю функциональность обеспечивает, а только заложенную в него. Если что-то выходит за рамки, например, транзакционность изменений групп св-в в рамках одного логического события, то как и везде — ручками.
Еще немного сбивает с толку несколько плохосвязанных задач:
— динамическое расширение набора св-в, дублирует IPropertyProvider, IExpando, а так же динамику 4-го дотнета;
— рефлексия, дублирует встроенную;
— с 0-ля сделали YA диспатчинг, старательно наступив на грабли, которые были побороты еще в ActiveX/DCOM;
Для завязки всей этой функциональности в "единую точку" в WinForms и в WPF есть одноименный объект Binding (связь, связка). Если WinForms сей объект "сам" строится из описаний атрибутов и принятых соглашений, то в WPF мы описываем промежуточную декларативную единицу — DependecyProperty, потеряв легковесность и распределенность подхода ComponentModel (например, в последней можно отфильтровать как сами св-ва для биндинга, так и подкорректировать принадлежащие св-вам аттрибуты, что дает доопределять или переопределять характеристики св-в).
MM>Давай рассмотрим сценарий attached behavior. Есть много разных контролов, переделать которые мы никак не можем. Есть простая задача: например мы хотим сделать простой биндинг к значениям, которые можно получить только в каком-нибудь событии этих контролов. Сейчас такое в WPF делается на ура, минут за 30. Как такое сделать в Windows Forms?
В XAML или в коде? Просто в коде "ручками" это на любой технологии за 5 мин делается, через определение интерфейса Model, к которой осуществляется биндинг (в смысле публичного интерфейса некоего типа, не обязательно interface как тип данных). А если речь о XAML, то это уже поддержка декларативности... И не уверен, что оправданная для такой задачи, бо XAML не очень хорошо смотрится в виде "визуального языка программирования". C# удобнее смотрится для порождения абстракций.
MM>Следующий вопрос. У меня есть класс, в нем есть свойство, на изменение которого я хочу реагировать. Оказалось так, что автор класса не озаботился написанием метода OnSomePropertyChanged.
Значит, это св-во не предназначено для непосредственного биндинга.
MM>Что предлагает в этом случае "самоописываемый подход"? Вешать обработчик через AddValueChanged плохо, потому что компонент навечно окажется в списке ссылок статического класса, следовательно никакой сборки мусора.
Нет, не поэтому плохо.
А потому, что если объект НЕ предоставляет события о внутреннем изменении св-ва, то вешать хук на изменении св-ва извне — это источник популярного бага. Напомню, что бывают св-ва, которые вычисляются при каждом вызове, даже если есть сеттер. В общем, не все св-ва тривиальные, иначе бы не было смысла вводить св-ва взамен публичных полей. Поэтому, зачастую может не быть нотификации, если для вычисления значения св-ва используются внешние опрашиваемые данные, т.е. которые тоже не дают нотификаций. Оставлю за рамками обсуждение кривизны таких решений, но они есть сплошь и рядом в обозреваемых третьесторонних либах. Т.е. при твоей попытке обыграть отсутствие нотификатора в этом случае ты потратишь время на проектирование нетривиального в поиске бага.
MM>Предусмотреть для всех контролов некий универсальный метод OnPropertyChanged?
Для простых сценариев установки значения можно и так, через некий INotifyPropertyChanged. Заметь, что интерфейс, как тип данных, гибче по своей природе. А для сложных сценариев бывает что угодно, вплоть до ручного суспенда биндинга (т.е. диспетчеризации в текущем фрейме), частичного rollback/commit и продолжения затем "обычного" биндинга. Да, согласен, в WPF предусмотрено довольно много популярных сценариев вокруг изменения и валидации св-в, но все предусмотреть априори невозможно.
MM>Хорошо, как будем проверять, какое именно свойство изменилось? Где взять некоторый идентификатор свойства? PropertyDescriptor? Покажи мне PropertyDescriptor в контракте хотя-бы одного контрола Windows Forms.
ICustomTypeDescriptor много где.
Ну и обязательный боксинг значений DependencyProperty тоже как бы намекает, что универсальностью сей подход не страдает, в отличие от ComponentModel, где мы не платим за каждую минимальную операцию только лишь из-за факта использования некоей инфраструктуры. Мне уже подумалось, может оно и правильно, что DependencyObject из WPF завязан сугубо на WPF, что как бы намекает, что не стоит пытаться использовать фреймворк как универсальный общего назначения. В WCF аналогично... на уровне остальных затрат расходы на боксинг не видны под микроскопом... Но это верно лишь в рамках этой задачи, поэтому тамошний брат-близнец DependencyObject тоже доступен лишь в рамках того фреймворка.
Здравствуйте, MxMsk, Вы писали:
MM>Хех, да скорее DependencyProperty в большей степени соответствуют порядку property->component->value. Ну, а DependencyObject можно рассматривать как частный случай компонента, имеющего set-аксессор.
Я имел ввиду не логически, а физически, как данные хранятся. Ну и внешний интерфейс, кстати, соответствует тому, как эти данные хранятся. Понятное дело, в обоих случаях (WPF/ComponentModel), когда контейнер награждает подчиненные объекты динамическими св-вами, он именно от целевых св-в пляшет, которые как бы константны, т.к. известны в compile-time и зашиты жестко в алгоритмы, но итерируется-то при этом по зависимым объектам времени исполнения... ИМХО, в компонентной модели такое отношение участников выражено в интерфейсах и их взаимодействии явно, т.е. прямо отражает происходяще. А в WPF мы получили YA реализацию шаблона "динамического объекта". А это залет, положа руку на... Бо совсем не хочется иметь неконтроллируемую компилятором (т.е. вне системы типов) возможность случайно присвоить не тому объекту значение не того св-ва (и испортить тем самым что-нить). В общем, здравствуй динамика во всей красе. В случае расширения по принципу компонентной модели извне нет никакого способа установить не то св-во не того объекта из-за приватной инкапсуляции всей логики вокруг расширяемых св-в и конкретного списка самих объектов конкретного контейнера.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ничуть. Как дотнета в винде не было, так его там и нет. Ничего не изменилось. ГВ>>Ну в этом смысле — безусловно. НС>А, то есть уже какие то альтернативный смыслы в ход пошли?
Какие ещё альтернативные смыслы? О чём ты?
НС>>>Удивление твое, оно от незнания реальной ситуации. ГВ>>Я никак не пойму, что ты называешь реальной ситуацией? НС>Реальные факты, а не фантастические теории.
Так я этих фактов гору вывалил. Копаться в истории сообщений RSDN не буду, увольте. Если интересно — поищи сам.
ГВ>>Ну и плюй на здоровье. Одно другого не отменяет: JCP — всё таки, некоторый формальный фактор, который так или иначе влияет на то, что Oracle сможет вытворять с Java. НС>Примерчик такого флияния реальный есть?
. Или AVK я тоже не должен доверять?
ГВ>>Объясняю — я смотрю на происходящее, как наблюдатель, который просто смотрит и, образно говоря, загибает пальцы — то появилось, это обещалось, то не появилось НС>Ага, при этом ты совершенно не собираешься различать, от кого обещания исходят. И выбираешь исключительно руководствуясь совпадениями с твоими собственными теориями.
С какими ещё теориями? Как раз, что до меня лично, то я считаю, что дотнету, в общем, ничего не угрожает. Просто он становится "не первым". А то, что я тут давеча изливал — так это было так, хихиканье (я сам в этом и расписался).
НС>>>И это если бы в Метро был SL, тогда действительно можно было бы говорить о каких то ощутимых изменениях. А сейчас, по факту, ничего не изменилось. Скорее наоборот — роль дотнета возросла, так как впервые низкоуровневое API параллельно разрабатывается уже с учетом интересов managed мира. ГВ>>А где там такой учёт? НС>Пастернака не читал, но осуждаю. Что ж, ожидаемо.
Я хочу услышать твоё мнение.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>MVP, они тоже разные бывают. ГВ>>Знаешь ли, звёздочек на них не нарисовано. НС>Не нарисовано. Но, знаешь ли, у тебя моск есть. И если орел регулярно чушь несет, то неважно, есть у него лычка MVP или нету. А то самые крикливые MVP, если поскрести, на поверку даже основные MVPшные мероприятия ни разу не посещали.
А мне оно надо — копаться в отличиях одного MVP от другого? Добро, когда информацию, исходящую от данного MVP я могу проверить сам, а если нет? Остаётся только уповать на его честность. Так что... Хотя спорить не буду — в последнее время лычка MVP уже себя несколько дискредитировала (в моих глазах, во всяком случае).
ГВ>> Так что, чем один MVP от другого отличается — тайна сия велика есть... НС>Верится что то с трудом в такое непонимание. Тем же, чем один человек от другого, ваш КО.
Ad hominem, мой друг, ad hominem. Дурак тот MVP или нет, несёт время от времени чушь или нет — вопрос четырнадцатый. К примеру, он может нести чушь по техническим вопросам, но при этом точно пересказать чьё-нибудь выступление (опять таки, по той же самой глупости). Так что, ad hominem.
ГВ>>Негатив, о котором говорит vdimas исходит как раз от дотнетчиков. НС>Я говорю про этот топик.
От кого тут негатив исходит? Люди озвучивают вполне реальные недостатки дотнета и политики MS. Если плюхи есть — то почему их констатация называется "негативом"? Повторюсь, волна воплей в этом году исходила вовсе не от традиционных "ругателей" дотнета.
НС>>>А почему devdiv индусы оккупировали, причем до самого верха, а талантливые разработчики оттуда пачками свалили? Почему Балмер во главе корпа? ГВ>>Так всё таки, какова твоя версия причин победы Синофски над Гатри? Ты не уходи от вопроса. НС>Не все ли равно?
Нет, не всё равно.
НС>К техническим аспектам это никакого отношения не имеет. Все дело в личностях — Синовский давно и много политикой занимается и весьма поднаторел в этом. А Гатри занимается IT исключительно ради удовлетворения личных интересов, и в политику до сего случая сильно не лез.
Ну, хорошо. Поясни тогда, пожалуйста, что означает: "давно и много политикой занимается" в данном контексте? В лицах и событиях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
