Рабочее

[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

[gds.livejournal.com]

> переход к началу.

так есть же метапрограммирование со строгой типизацией, зачем к началу-то. Дальше идти надо.

а гирлянда -- жесть. Я бы ебанулся. Если .net является требованием, проще F# взять.

[wizzard]

В Nemerle есть нормальный type inference и гораздо больше метапрограммирования.

А еще мне всегда казалось, что System.ComponentModel несколько ущербно задизайнена, как и виндовс формс, для которого, вроде, оно было сделано.

[metaclass.livejournal.com]

Да, на немерле надо опять смотреть, в прошлый раз руки не дошли его прикрутить к продакшену.

А вот ComponentModel и Windows.Forms это да, безумие. В рефлекторе на внутренности страшно смотреть.

[wizzard]

у меня немного ухудшилось впечатление о нём после (успешных, в итоге) попыток билда svn head (бинари на сайте древнейшие и глючные), но вообще проект жив и вполне привлекательно выглядит.

[dmzlj.livejournal.com]

Вроде немерле не продакшн. т.е. это будет реально рывок в неведомое. Кастомеры оценят.

[metaclass.livejournal.com]

Таки да, это меня в общем-то и останавливает.
Но я предполагаю, что это ненамного страшнее реализации самодельных языков, виртуальных машин для микроконтроллеров и использования в продакшене llvm :)

[dmzlj.livejournal.com]

Я смотрю кто и как это немерле пилит, и к чему они в результате пришли. Не внушаить. Ващще.

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

[metaclass.livejournal.com]

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

[dmzlj.livejournal.com]

А может генерация кода это нормально?

[alexott.livejournal.com]

F# ?

[themech.livejournal.com]

привет вам кстати, ребе, из гродненских лесов
те, кто вовремя успел перейти на линукс, сейчас тут загорают, жарят шашлыки и купаются в озере ;-)

[blackyblack.livejournal.com]

Надо забыть ООП как страшный сон. И сразу станет легче.

[metaclass.livejournal.com]

Альтернативы объектной декомпозиции как средству анализа предметных областей вообще нет. Хотя в данном случае вся проблема в том, что в дотнете, когда разрабатывались классы из этого неймспейса, функций высшего порядка в нормальном виде не было. Да они и сейчас не то, чтобы сильно пригодны для таких целей.

[blackyblack.livejournal.com]

Ну здрасьте. Декомпозиция разная бывает и альтернативы есть.
Лично я произвожу декомпозицию сначала процедурную, а по мере взросления проекта разбиваю задачу на модули, которые вовсе не обязаны быть объектами.

[metaclass.livejournal.com]

У меня вся первичная информация представлена в виде не столько объектов, сколько записей, или даже ADT. Потом это все приходится делать в виде объектов, другого в ООП языках как бэ не предусмотрено. Всякий там ввод данных юзерами и тому подобное.

А вот всевозможные запросы-отчеты-расчеты-ведомости используют функциональную декомпозицию, на нее они ложатся гораздо лучше.

[volodymir-k.livejournal.com]

С удовольствием выслушаю Ваше не-ООП решение этой проблемы.
Ещё раз, напоминаю, в чём именно проблема:
* Надо позволить юзерам создавать БД и описывать формы для его взаимодействия путём показа описывающих сущности этой БД форм. БД заранее неизвестна. Также юзер должен мочь изменять это своё описание. Также юзер должен мочь добавлять произвольные атрибуты, которые потом будут использоваться сторонней программой.

Вы сделаете абсолютно такой же дизайн. Да, названия сущностей и методов будут другие, а состав данных - тот же.

Проблема не в ООП совсем -- если приглядитесь, в записи только обычные типы, никакого наследования не требуется. Можно точно так же пенять, дескать XML виноват. Альтернатива ничем не будет лучше.

[metaclass.livejournal.com]

Слава богу, тут юзера списки полей не редактируют. Но заранее он неизвестен, да, его предоставляют разработчики софта, для которого мой отдает объекты конфигурации.

[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).
А наследование просто нахрен не нужно, да его и в обычном ООП уже почти не используют - кроме наследования классов от интерфейсов, что в свою очередь и реализуется классами типов.