![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Пока ребе белнетмона отвлекли настраивать долбосервера, я втайне доделываю его код, который основан на другом моем коде.
Конкретно, код представляет собой обход дерева-модели меню с созданием непосредственно этого самого меню. У меня были реализации для WindowsForms (Menu и ToolStrip) а ребе сделал его для wpf. Ну тут вам не хаскель, HOF для обхода дерева не сделаешь и структурку с функциями для генерации пунктов меню не передашь (хотя, насчет этого см. ниже), поэтому есть базовый класс, от него унаследованы три реализации.
В моих реализациях чтобы выйти на уровень выше в генерируемом дереве по событию выхода в обрабатываемом я использовал стандартные проперти элементов типа там OwnerItem. Если мне не изменяет память, эта проперть находится буквально за пару минут в MSDN в описании соответствующего класса элемента меню. И пропертей там раз-два и обчелся и они все понятные.
Так вот, для WPF класса MenuItem я искал это в MSDN минут 10 и ничерта не нашел. Есть свойство Parent, но оно указывает на само меню, а на не элемент меню-владелец. В итоге положил болт и сделал поле Stack<MenuItem> для хранения той же информации, это заняло не больше минуты и, ЧСХ, я точно уверен что это будет работать, т.к. это зависит только от "первых принципов", т.е. общего представления о стеках и деревьях.
В связи с этим вопрос: кто дебил, я или таки разработчики GUI фреймворков в микрософте? Почему в последнее время практически всегда оказывается быстрее сделать собственную реализацию чего-то, чем разбираться с готовыми?
Вернее, не совсем так. Есть вещи, в которых разобраться проще чем сделать свое - базы данных, компиляторы, ОС, чо там еще. По идее, ключевой аспект, отличающий вещи, с которыми проще разобраться - строго ограниченный понятный API/язык/набор базовых концепций/теория.
А вот, например, в WPF, похоже, засунули или попытались засунуть вообще все, до чего смогли дотянуться загребущими ручонками, но оформить это в виде строгой концепции, а не реализуя over 9000 классов, интерфейсов, xml схем и скручивая это все рефлекшеном - не смогли.Потому что на лекции хаскелистов из Microsoft Research сходить поленились, придурки раССово-индуССкие, в отличие от разработчиков собственно фреймворка
Да, и таки про хаскель: по идее в генераторе меню можно заменить наследование классов одним генерик-классом зависящим от типа пункта меню(и, возможно, самого меню) и передавать в его конструктор стопку функций типа "создать пункт меню", "создать сепаратор", "создать субменю" и тогда вся логика обхода дерева будет жыдь в одном классе, а действия выполняемые при обходе будут жыдь в передаваемых функциях.
Но это будет выглядеть еще сложнее, чем сейчас, а оно уже сейчас выглядит как набор задач для издевательства над теми, кто утверждает что "умеет .NET" на собеседованиях.
Конкретно, код представляет собой обход дерева-модели меню с созданием непосредственно этого самого меню. У меня были реализации для WindowsForms (Menu и ToolStrip) а ребе сделал его для wpf. Ну тут вам не хаскель, HOF для обхода дерева не сделаешь и структурку с функциями для генерации пунктов меню не передашь (хотя, насчет этого см. ниже), поэтому есть базовый класс, от него унаследованы три реализации.
В моих реализациях чтобы выйти на уровень выше в генерируемом дереве по событию выхода в обрабатываемом я использовал стандартные проперти элементов типа там OwnerItem. Если мне не изменяет память, эта проперть находится буквально за пару минут в MSDN в описании соответствующего класса элемента меню. И пропертей там раз-два и обчелся и они все понятные.
Так вот, для WPF класса MenuItem я искал это в MSDN минут 10 и ничерта не нашел. Есть свойство Parent, но оно указывает на само меню, а на не элемент меню-владелец. В итоге положил болт и сделал поле Stack<MenuItem> для хранения той же информации, это заняло не больше минуты и, ЧСХ, я точно уверен что это будет работать, т.к. это зависит только от "первых принципов", т.е. общего представления о стеках и деревьях.
В связи с этим вопрос: кто дебил, я или таки разработчики GUI фреймворков в микрософте? Почему в последнее время практически всегда оказывается быстрее сделать собственную реализацию чего-то, чем разбираться с готовыми?
Вернее, не совсем так. Есть вещи, в которых разобраться проще чем сделать свое - базы данных, компиляторы, ОС, чо там еще. По идее, ключевой аспект, отличающий вещи, с которыми проще разобраться - строго ограниченный понятный API/язык/набор базовых концепций/теория.
А вот, например, в WPF, похоже, засунули или попытались засунуть вообще все, до чего смогли дотянуться загребущими ручонками, но оформить это в виде строгой концепции, а не реализуя over 9000 классов, интерфейсов, xml схем и скручивая это все рефлекшеном - не смогли.
Да, и таки про хаскель: по идее в генераторе меню можно заменить наследование классов одним генерик-классом зависящим от типа пункта меню(и, возможно, самого меню) и передавать в его конструктор стопку функций типа "создать пункт меню", "создать сепаратор", "создать субменю" и тогда вся логика обхода дерева будет жыдь в одном классе, а действия выполняемые при обходе будут жыдь в передаваемых функциях.
Но это будет выглядеть еще сложнее, чем сейчас, а оно уже сейчас выглядит как набор задач для издевательства над теми, кто утверждает что "умеет .NET" на собеседованиях.
