Рабочее

[metaclass]

Удар головой о стенку, обитую войлоком
"Хочу строгой типизации"
Удар головой о стенку, обитую войлоком
"Хочу автоматический вывод типов"
Удар головой о стенку, обитую войлоком
"Хочу метапрограммирование"
переход к началу.

Альтернатива:
для объекта Config регистрируется TypeDescriptionProvider, который создает и возвращает CustomTypeDescriptor, который из ServiceProvider достает XmlConfigProvider, загружает из него список кастомных свойств объекта, для каждого из них генерит ConfigPropertyDescriptor, добавляя к нему CategoryAttribute,DisplayNameAttribute,DescriptionAttribute,иногда TypeConvertorAttribute и ChoiceDescriptionAttribute, указав для них ChoiceConverter, который возвращает StandardValuesCollection, исходя из ChoiceDescriptionAttribute, найденного в TypeDescriptorContext.

Это всего лишь показ объекта в user-friendly виде с локализованными именами пропертей и динамически меняющимся их списком в PropertyGrid.

PS: А тут еще max_posedon всякую завлекаловку с LVEE про линуксы и железо пишет. Хоть ты точно, на линукс и какой-нибудь трэшак типа руби с питоном пересядь, чтобы этого дотнета с его гирляндами типов никогда не видеть. Или вообще на low-level работу с железом, там уж ТОЧНО НИКОГДА не придется писать что-нить вроде IServiceProviderFactoryOfProviderForServiceProviderFactoryFacade.

Comments

[blackyblack.livejournal.com]

Я считаю, что нельзя просто так давать пользователям что-либо создавать в БД. Это такое стремление к универсальности, которое приводит к монстроидальному софту.

Не ООП подход такой, что задачу стоит рассмотреть с точки зрения поставляемых сервисов. То есть ход мысли примерно такой:
1. Что мы будем поставлять клиенту - сервис предоставления отчётов и форм и прочей дребедени на каждый чих? Тогда не будем давать пользователю ничего в руки и писать такие сервисы самостоятельно.
2. Если мы будем предоставлять клиенту сервис для самостоятельного создания дребедени, то пишем такой сервис с приемлемым АПИ (типа REST) и ставим бэкендом хоть БД, хоть что угодно.
3. Нужно ли тут ООП? Вопрос религии. В любом случае это будет внутренняя кухня и клиент никаких иерархий не увидит, а видеть будут создатели сервиса.

Но это всё домыслы, а критерий истины практика. Поэтому я и предложил метаклассу сообщить, как только он придумает идеальный дизайн этой кухни.

[volodymir-k.livejournal.com]

> Это такое стремление к универсальности, которое приводит к монстроидальному софту.

Здрасьте-приехали. Бухгалтера уже лет 10 как метадату редактируют в 1С, а вообще-то небось ещё в 1980-х было. Ничего там монстроидального нет.

> Тогда не будем давать пользователю ничего в руки и писать такие сервисы самостоятельно.

А конкуренты будут. И дают. Что-то бухгалтера не Ваше поделие юзают, а почему-то 1С.

> Нужно ли тут ООП? Вопрос религии.

Повторюсь: "С удовольствием выслушаю Ваше не-ООП решение этой проблемы."

По факту, современные ООП-классы выросли из С++-ных, а те -- из struct-ов. Ранний Страуструп так и говорил: это альтернативная нотация для struct, у которых ещё и методы есть. Просто в какой-то момент Вы сами запаритесь всюду передавать this и тягать из него поля, и вуаля.

[blackyblack.livejournal.com]

"А конкуренты будут. И дают. Что-то бухгалтера не Ваше поделие юзают, а почему-то 1С."
1C очень долго был глюкавым чудищем. Я же не говорю, что так делать совсем нельзя - просто поддерживать сложнее, чем без такого подхода. Что и почему юзают бухгалтера не очень сильный довод - тут масса факторов, начиная со времени выхода на рынок, имеющихся ресурсов...

"По факту, современные ООП-классы выросли из С++-ных, а те -- из struct-ов."
Как устроен ООП я как бы в курсе. Но его необходимость преувеличена. Я видел кучу фреймворков и АПИ без всяких признаков ООП.
Чтобы не тягать this можно его просто разместить видимым внутри модуля и все методы модуля о нём знают. Для "как бы" полиморфизма используются коллбэки. Наследование вообще не используется как опасное.

Чтобы дать конкретное не-ООП решение "этой проблемы" нужно уточнить, какая проблема имеется в виду. Если под проблемой понимается реализация собственных форм и обработчиков пользователя, то я бы сделал систему типа плагинов и регистрировал точку входа в плагин в некотором реестре. Сами же плагины чтобы писались на произвольном языке.

[metaclass.livejournal.com]

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

Где-то в интернете валяется статья на тему OOP vs Haskell. Там описывается, что большая часть ООП становится нахрен не нужна при наличии функций высших порядков/лямбд/замыканий. Конкретно в моем описанном случае половина интерфейсов/классов исключительно служат оболочками для реализации этого всего вручную.
Полиморфизм добавляется классами типов, за одним исключением - разные объекты внутрь списка просто так не поместишь для однообразной обработки, поэтому нужен экзистенциальный тип(насколько я понял, это оболочка вокруг обычного типа, накладывающая на него условие вроде "все вложенные типы являются экземплярами класса типов X).
А наследование просто нахрен не нужно, да его и в обычном ООП уже почти не используют - кроме наследования классов от интерфейсов, что в свою очередь и реализуется классами типов.