RTTI насколько сие необходимо и полезно? (3 стр)

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

Pushkoff
> 1%

Ну ещё, например, у меня там много разных типов элеметов может быть. Каждый из них имеет различное количество свойств (координаты, размеры, цвет, текст - стандартные, а также бывают и всякие другие). Задача: иметь возможность считать все значения всех свойств всех объектов и сохранить в файл, а также потом из файла загрузить. Если бы я использовал C++, мне бы пришлось очень туго. А на C# я просто с помощью рефлекшена получаю значения всех свойств, перегоняю их в строковую форму и записываю в XML.

Правка:

Я немного недоговорил. На самом деле задача чуть сложнее. Например, нужно не все свойства обрабатывать, а только те, которые предназначены для взаимодействия с пользователем. Потому "нужные" свойства я ещё помечаю соответствующим атрибутом и потом сохраняю/загружаю только те свойства, у которых такой атрибут имеется. Ещё, например, некоторых свойств может не быть в последующих версиях, потому нужно предупреждать пользователя о том, что файл загружен в режиме совместимости, но при этом работать корректно. Т.е. в общем случае, есть подсистема, за это отвечающая + позволяющая себя расширять специальными трансформаторами, которые отображают старые сохранённые свойства на новую модель. Ну и т.д. Потому, рефлекшн тут ещё более нужен.

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

Почему же я неправильно понял? Нужно иметь набор пар ("строка с именем" - "некоторый код").

Правка:

У меня для этого есть базовый класс Command, от которого наследуются все классы, с которыми могуть связываться элементы меню, определяемые в XML. Класс объявляет абстрактные методы (типа Execute), собсна выполняющий команду. Есть менеджер команд, который отвечает за двухстороннюю связь "элемент меню" <-> "объект класса команды". Двусторонняя связь нужна потому что, например, когда отрабатывают некоторые команды, пункты меню могут дизейблиться и т.д.
Есть ещё не простые команды, способные порождать подкоманды (и, как следствие, выстраивать дерево подменю на основе подкоманд), ну т.д.

Pushkoff
> а правильное решение лежит немного в другой плоскости и требует смены архитектуры в целом...

Всмысле?

.NightmareZ.
> Ну ещё, например, у меня там много разных типов элеметов может быть.
у нас это решается при билде данных, то есть в файле хранится идентификатор данных, по которому данные выгребаются в структуру определенного типа (функция выгребания тоже генерируется), потом это передается в функцию загрузки, она просто читает то что ей нужно уже из структуры...

.NightmareZ.
> ("строка с именем" - "некоторый код").
это я уже привел задачу к такому решению, так как оно мне показалось удобным... но от проблемы это не избавило, только раньше это был длинный if..else if либо switch..case, теперь это функция, причем и в твоем и в моем случае... но даже небольшие изменения работы скрипта начали сильно сводить необходимость вызова функций из основного кода к минимуму, делая ненужным рефлекшн в принципе...

Pushkoff
> у нас это решается при билде данных, то есть в файле хранится идентификатор данных, по которому данные выгребаются в структуру определенного типа (функция выгребания тоже генерируется), потом это передается в функцию загрузки, она просто читает то что ей нужно уже из структуры...

Т.е. у вас написана отдельная утилита, генерирующая код по данным?

.NightmareZ.
по описаниям данных...

Pushkoff
> по описаниям данных...

Ну да, я это и имел ввиду. Но ведь, наверное, отлаживать это не очень удобно?

.NightmareZ.
это не нужно отлаживать, это сгенерированный код, он уже верен и если в нем есть ошибки то отлаживать нужно генератор, а он на питоне...

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

.NightmareZ.
> Ну раз такая пьянка пошла, одепты C++ могут мне рассказать, как на C++ делать что-то подобное (и возможно ли это вообще)?
Ты мне скажи. Это всё конечно классно, МОЩ языка и всё такое.
Но ты для себя код пишешь? Потому что очень сомневаюсь, что в подобном говноедсте кто-то ещё кроме тебя будет разбираться, если ты такие же темы продвигаешь в нормальном проекте.

кстати о лямбдах. буквально на днях одному моему знакомому довелось рефакторить шарповский код залямбденный посамое не хочу. на поиск банальной ошибки ушло две недели. я к чему это. .NightmareZ., если вдруг твой код кто то будет поддерживать - икоты необерёшься.

я конечно понимаю, что это крайне маловероятно. говорю так, к сведению.

MAMOHT-92
> в конфиге пишем имена переменных и их значения, зачем используя RTTI легко
> инициализировать поля значениями из конфига, профит, не?

MySuperClass.SomeField = MySuperConfig.ReadInteger('SomeValue', DefaultValue);
Легко инициализировал без всяких там RTTI...

Nomad
> Но ты для себя код пишешь?

И для себя пишу и не для себя.

Nomad
> Потому что очень сомневаюсь, что в подобном говноедсте кто-то ещё кроме тебя
> будет разбираться, если ты такие же темы продвигаешь в нормальном проекте.

Просто ты не профпригоден.