Рабочее

[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С."
1C очень долго был глюкавым чудищем. Я же не говорю, что так делать совсем нельзя - просто поддерживать сложнее, чем без такого подхода. Что и почему юзают бухгалтера не очень сильный довод - тут масса факторов, начиная со времени выхода на рынок, имеющихся ресурсов...

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

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

[metaclass.livejournal.com]

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

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