Здравствуйте, VladD2, Вы писали:

ГВ>>Что-то ты странное говоришь. Что ты подразумеваешь под словом "дыра"?

VD>Думаю, ты и сам понимаешь. Дыры — это отсуствие в языке/рантайме простых конструкций решающих стоящие перед тобой задачи. Например, когда стоит задача вызывать метод у абстрактного объекта... или когда стоит задача сделать что-то на сосновании описания типа.

А зачем вызывать метод у абстрактного объекта? Метод всегда вызывают для чего-то определённого. А значит, это не абстрактный объект, а вполне конкретный.

VD>Все примеры приведенные в том посте делаются на Шарпе элегантно и просто. При этом Шарп ведь не обладает такими мощными средствами самомодификации. Мысль ясна?

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

Здравствуйте, AndrewVK, Вы писали:

ГВ>>>>Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится.
AVK>>>Что значит полностью автоматически?
ГВ>>Custom-атрибуты автоматически добавляются?
AVK>А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения.

Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...

AVK>В большинстве случаев можно обойтись и без них, штатная информация весьма богата. И потом — принципиальное отличие атрибутов от шаблонов в том что атрибуты это сугубо декларативная сущность, они не содержат алгоритмической части, а значит вероятность ошибки крайне низка.

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

А зачем там такой анализ? Там все проще будет — достать из атрибута тип конвертера, создать экземпляр, вызвать метод.

Т.е., атрибут является носителем ссылки на тип (вероятно — имени класса), т.е. — на совокупность методов и данных. В определённом смысле — класс как класс. Кстати, в дальнейшем ты продемонстрировал пример вполне себе даже LSP-compliant решения. Недостаток один — атрибуа может не оказаться.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>>Забавно. Правильно сказали — если рефлекшен позволяет создаватьболее красивые и лаконичные решения, так может стоит пересмотреть свои оценки дизайна?
ГВ>>Причём здесь оценки дизайна?
AVK>При том что твое заявление что дизайн с использованием "самоанализа" безусловно кривой неверно.

Так, ну поехали ещё раз. Анализ всегда преполагает разбор чего-либо на составляющие, выделение известных анализатору символов. Соответственно, он a'priori преполагает, что этих симовлов может не быть.

С точки зрения оценки системы — наличие в ней самоаналитических сегментов обязательно сказывается на быстродействии и надёжности. Почему первое — понятно, а второе — потому что работа по гарантированию целостности системы перекладывается на цикл тестирования, который и должен гарантировать, что система — цельная. Тестированием управляют прежде всего люди, а сложность системы растёт и потому это — ненадёжно.

ГВ>>Если рефлекшн можно использовать в рамках вполне приличного дизайна (твой пример о конвертерах неизвестных типов), то никаких противоречий нет.
AVK>То есть ты признаешь что твое первое заявление было неверным?

Нет, поскольку:

а) Рефлекшн и RTTI — разные, хотя и похожие вещи. Reflection (буквальный перевод — "отражение") — он сам по себе, хотя и реализует функциональность RTTI. Соответсвенно, неправомерно было контраргументировать (и я это не сразу понял) мой тезис с помощью примера, построенного на reflection-е, тем более, что там и преимуществ-то его особо показано не было.

б) Ты приводил мне пример, в котором RTTI-based подход к проектированию выражен слабо и в сущности — оправдан, поскольку речь шла о разновидности лексического анализа входных данных, т.е. структуры символов, внешних по отношению к программе. В пределе эта задача превращается в обычный компилятор.

в) Подход к проектированию, основанный на том RTTI-анализе, который я имел ввиду (а я уже объяснял — что именно это такое) неизбежно влечёт ряд недостатков, снижение быстродействия — в первую очередь (что и составляло основную мысль моей фразы).

г) Что характерно, и для твоего и для моего примера реализации обработки входных данных характерны одни и те же ситуации — потенциальная runtime-ошибка в результате отсутсвтия нужного обработчика и снижение скорости работы, поскольку и там и там есть цикл поиска обработчика. И это лишний раз подтверждает мои слова, если уж притянуть к этому примеру определение "RTTI-based дизайн" поскольку анализ какой-никакой, а всё-таки здесь есть.

Здравствуйте, AndrewVK, Вы писали:

ГВ>>Да, не спорю, эмиттинг это позволяет, но проблема в другом — в правилах и алгоритмах сборки кодогенератора. Они-то откуда появятся?
AVK>На основании информации из рефлекшена.

На каком основании — это неважно в данном случае. Откуда появятся сами правила? Какая программа будет делать вывод о применимости того или иного правила?

AVK>>>Все равно кривой дизайн. И дело не в окружении, дело в подходе. В нете я могу спокойно планировать очень широкое использование рефлекшена, потому что использовать его ничего в плане дизайна не стоит.
ГВ>>Дизайн всегда стоит одинаково.
AVK>Вот как раз ничего подобного. К сожалению красивая сказка о том что дизайн не зависит от инструмента для его реализации всего лишь сказка, инструмент накладывает серьезные ограничивающие или наоборот стимулирующие факторы на возможность применения тех или иных дизайнерских решений. И не учитывать это в дизайне по меньшей мере глупо.

Да, с последней частью твоего выказывания я в принципе согласен, но например, LSP сформулированы не для конкретного C++ или CLU и их использвание не зависит от используемого средства. Да и твой пример блестяще это подтверждает. Это достаточно общий принцип, также, кстати, неоднократно подтверждённый практикой.

AVK>>>На плюсах же аналогичные алгоритмы с некоторого момента весь привнесенный плюс погребут под огромным количеством служебного кода и снижением удобства модификации программы.
ГВ>>Очень и очень спорное обобщение, что на C++ — обязательно погребут.
AVK>Это вывод на основании практики использования.

Тебе не повезло.

AVK>>> И если С++ не позволяет реализовать задачу как то иначе то это проблемы именно С++.
ГВ>>Или дизайнера, что, ИМХО — чаще.
AVK>Бестолковый аргумент — на неумелость дизайнера можно свалить что угодно.

На язык — тоже.

Здравствуйте, VladD2, Вы писали:


VD>Слушай, объясни мне одну вещь. Вот в области С++ на этом сайте есть два авторитета: Андрей Тарасевич и Павел Кузнецов. Я с ними не однократно спорил не тему крутости/убогости С++. Почему ни одни из них не тыкла меня носом в незнание С++, а у ты с WolfHound этим занимаешся?

Кстати, неплохо было бы узнать, что Андрей Тарасевич и Павел Кузнецов думают об Александреску

Здравствуйте, VladD2, Вы писали:

VD>Лучший пример тут дотнет. В нем даже придумали специальное расширение метаданныж — атрибуты. Представсь себе помещаешь ты метод атрибутом:
VD>

VD>[MenuText("Открыть файл"), Shotrcut(Keys.Ctrl & Keys.O), Img("FileOpen")]
VD>void OpetFile(){ ... }
VD>

VD>И у тебя как по мановению волшебной плочкой в программе появляется менюшка, шоткат и иконка в тубларе.

Я не нахожу это решение очень уж красивым, хотя нечто такое же я неоднократно делал на C++, только выглядело по-другому, примерно так:

MenuItem file_open("Открыть файл", "FileOpen.ico", &global_file_operations::file_open);

VD>И никакого кодирования и отладки. Даже дизайнер не нужен.

Я тоже без дизайнера обхожусь в ряде случаев.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.

Мне не нравится следующее:

1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?
2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> А зачем вызывать метод у абстрактного объекта? Метод всегда вызывают для чего-то определённого. А значит, это не абстрактный объект, а вполне конкретный.

Ресское слово абстрактный не обязательно означет " = 0;".

ГВ>Ясна, конечно, но ведь речь-то шла о подходе. А сериализация это так... мелкая частная задача, на которую я обычно даже особого внимания-то не обращаю. Впрочем, это уже оффтопик.

Сериализация — это всеголишь пример. И таких примеров много. В общем, не стоит обвинять подход только на основании того, что в твоем любимом языке его применение больше похоже на половое изврещение.

Здравствуйте, Nose, Вы писали:

N> Я просто книжку _посоветовал_ прочитать. Или тебя так раздражают советы тех, у кого меньше опыта, чем у тебя?

Лпдно. Извени. Просто тут до тебя уже советовали эту книгу в особо извращенной форме. Да и любой совет можно нормально воспринимать только 2-3 раза.

N> (Кстати, неплохо было бы узнать, что Андрей Тарасевич и Павел Кузнецов думают об Александреску)

Это не трудно. За одно узнай читали ли они его вообще.

Здравствуйте, VladD2, Вы писали:

ГВ>>Я говорил о подходе. То, что в частном случае вытряхивание информации о структуре типа полезно — никак не отрицает недостатков RTTI-bases.

VD>Да нет никаких недостатков "RTTI-bases". Есть разумное и не разумное использование некоторых подходов в конкретных условиях. Информация о типах полезна везде, где есть необходимось добиться универсальности в рантайме. Везде где можно обойтись компайл-таймом она не нужна.

Влад, о чём спорим-то? Ясное дело — есть разумное и неразумное использование. Но характерные черты-то остаются в любом случае. У VMT тоже есть недостатки. И у шаблонов есть недостатки. И у RTTI-bases они есть. Как ты его не называй, но RTTI-bases обладает своими специфическими характерными чертами — относительной универсальностью с одной стороны и... ну я уже перечислял — с другой.

Здравствуйте, VladD2, Вы писали:

ГВ>> А зачем вызывать метод у абстрактного объекта? Метод всегда вызывают для чего-то определённого. А значит, это не абстрактный объект, а вполне конкретный.
VD>Ресское слово абстрактный не обязательно означет " = 0;".

Именно, а компьютерный "абстрактный объект" всегда представляется чем-то конкретным. И уж точно не " = 0", если речь идёт о работающем объекте.

ГВ>>Ясна, конечно, но ведь речь-то шла о подходе. А сериализация это так... мелкая частная задача, на которую я обычно даже особого внимания-то не обращаю. Впрочем, это уже оффтопик.
VD>Сериализация — это всеголишь пример. И таких примеров много. В общем, не стоит обвинять подход только на основании того, что в твоем любимом языке его применение больше похоже на половое изврещение.

С чего ты взял, что я критикую подход всего лишь "на основании того, что в моём любимом языке..."? Если бы всё было в этом подходе "шоколадно", то JIT-компиляция не потребовалась бы. А критиковали его ещё очень давно. С тех пор, как Lisp появился.

Здравствуйте, VladD2, Вы писали:

N>> (Кстати, неплохо было бы узнать, что Андрей Тарасевич и Павел Кузнецов думают об Александреску)
VD>Это не трудно. За одно узнай читали ли они его вообще.


ну... Павел Кузнецов, по-крайней мере, читал: здесь

Автор: Павел Кузнецов
Дата: 15.02.03

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Да, не спорю, эмиттинг это позволяет, но проблема в другом — в правилах и алгоритмах сборки кодогенератора. Они-то откуда появятся?
AVK>>На основании информации из рефлекшена.

ГВ>На каком основании — это неважно в данном случае. Откуда появятся сами правила? Какая программа будет делать вывод о применимости того или иного правила?

А какое это имеет отношение к применимости или неприменимости рефлекшена?

AVK>>Бестолковый аргумент — на неумелость дизайнера можно свалить что угодно.

ГВ>На язык — тоже.

Язык нет, его возможности вполне объективны, в отличие от рассуждений о криворукости гипотетического дизайнера.

Здравствуйте, VladD2, Вы писали:

AVK>>Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.

VD>Я бы оценил на 3 с плюсом.

С чем сравнивал?

Здравствуйте, _Kostya_, Вы писали:

_K_>1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?

Можно

_K_>2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.

Это смотря какой массив. Если byte[] то сохраняет в бинарном виде как base64

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> Я не нахожу это решение очень уж красивым, хотя нечто такое же я неоднократно делал на C++, только выглядело по-другому, примерно так:

Неужели не видишь разницы между декларативным заданием и экзекутивным? Твой вариант более багоопасен и более сложен для понимания. Опять же ты лукавишь — в твоем коде отсутствует механика добавления айтема в коллекцию.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ещё раз. Я говорил о дизайне и описал, какой именно дизайн я имею ввиду.
AVK>>Ты говорил что применение "самоанализа" это кривой дизайн. Перечитай еще раз свой пост.

ГВ>Совершенно верно, я даже описал — какой именно дизайн.

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

AVK>>Ничего подобного. Структура ровно так же может описываться в метаданных.

ГВ>Ага, что и говорит об известности, но достигаемой путём обработки описания этой структуры. Дотнет ведь генерит описание структуры класса и т.п. При этом обязательно делаются предположения о способах использования тех или иных типов данных, либо типы данных содержат дополнительную информацию, касающуюся их использования в определённых ситуациях.

Это уже демагогия. Естественно что код, использующий рефлекшен знает что работать он будет таки с классами, а не бог знает с чем. Но не более того. Все остальное пустопорожний треп и попытка перевести спор на терминологию.

ГВ>Зато он настроен на определённый входной язык — сиречь язык описания структуры дотнетовских классов и делает предположения об адекватных способах редактирования.

И что? Какой из этого вывод? Точно так же можно сказать что он настроем на работу с 8-мибитными байтами. Проблема только в одном — все данные, которые присутствуют в дотнете на 100% соответствуют структуре дотнетовских классов. А знание о структуре всех данных эквивалентно тому что никаких специфических знаний, присущих конкретной предметной области нет. Этими знаниями обладает любой код в дотнете.

ГВ>Никакого противоречия тут нет. Более того, должны существовать ситуации, в которых он окажется неадекватным и потребуется его замена.

"Существуют ситуации" и "необходима всегда" все таки несколько разные случаи.

AVK>>Но твое то утверждение было безусловным, не ограничивающим область применения.

ГВ>Я несколько некорректно его сформулировал, забыл, что термин "RTTI" успел приобрести другое значение. В частности — для тебя.

Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения. Повторяю — не пытайся перевести спор на термины, со стороны это выглядит как попытка выкрутиться.

ГВ>Моё утверждение о "самоанализе", естественно, не распространялось на ситуации анализа внешних данных, как не распространяется на них определение RTTI. Имелись ввиду только ситуации, в которых программа начинает анализировать свой сосбственный состав.

Во первых — твоя реплика была ответом на вот это:

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

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, _Kostya_, Вы писали:

_K_>>1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?

AVK>Можно

Наверное этот вопрос не для этого форума, а как? Смотреть код в исключении?

_K_>>2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.

AVK>Это смотря какой массив. Если byte[] то сохраняет в бинарном виде как base64

Да нет, массив объектов. Вот для словарей вместо
<dic lang="2" n="2" up="1" value="asd1"/>
<dic lang="2" n="3" up="1" value="asd2"/>
<dic lang="2" n="4" up="1" value="asd3"/>
<dic lang="2" n="5" up="1" value="asd4"/>

Получаем 
<dic>
 <lang>2</lang>
 <n>2</n>
 <up>1</up>
 ну и так далее
</dic>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>а) Рефлекшн и RTTI — разные, хотя и похожие вещи. Reflection (буквальный перевод — "отражение") — он сам по себе, хотя и реализует функциональность RTTI.

Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Custom-атрибуты автоматически добавляются?
AVK>>А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения.

ГВ>Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...

Какой библиотеки? Речь не о данных библиотеки, а о данных среды исполнения. Естественно что они содержат ровно тот набор, который необходим для функционирования дотнета. Если тебе этого недостаточно то можно метаданные расширить при помощи атрибутов. Уж сколько раз твердили миру — рантайм дотнета это не набор библиотечек как в С++, это совершенно особая сущность, неотделимая от понятия программирования в дотнете и от его языков.

ГВ>Т.е., атрибут является носителем ссылки на тип (вероятно — имени класса), т.е. — на совокупность методов и данных. В определённом смысле — класс как класс. Кстати, в дальнейшем ты продемонстрировал пример вполне себе даже LSP-compliant решения. Недостаток один — атрибуа может не оказаться.

Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.