Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным?
ГВ>Что ты подразумеваешь под "обычным"?
То чем занимашся ты. Долбление кода для решения любой задачи.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Именно, а компьютерный "абстрактный объект" всегда представляется чем-то конкретным. И уж точно не " = 0", если речь идёт о работающем объекте.
Не прикидывайся. Речь идет о любом (некотором) объекте.
ГВ>С чего ты взял, что я критикую подход всего лишь "на основании того, что в моём любимом языке..."? Если бы всё было в этом подходе "шоколадно", то JIT-компиляция не потребовалась бы. А критиковали его ещё очень давно. С тех пор, как Lisp появился.
С того, что о дотнете ты слышал краем уха. Если бы это было не так, то как минимум ты не говорил бы о JIT-компиляции. Так как она никакого отношения к рефлекшону не имеет. Если не веришь, сделай поиск по msdn на слово ngeg. Это утилита которая позволяет прекомпилировать msil, но рефлекшон при этом полностью доступен. Это так же как в TLB в COM, только формат храниния стандартизирован.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Чем тебе паскалевские указатели не угодили? Ровно такие же как и в С++, кроме наличия в последнем адресной арифметики.
Гы-гы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения.
Вот ксатати, именно по этому мне этот термин не нравится. Дотнетный рефлекшон доступен еще на дизайн-тайме. А в С++-ном rtti даже понятия такого как дизайнтайм нет.
AVK>Повторяю — не пытайся перевести спор на термины, со стороны это выглядит как попытка выкрутиться.
Что значит выглядит? Это она и есть. Собственно по этому мне этот спор уже больше не интрересен.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?
Вообще-то он предостовляет механизм динамического вызова. Ну, и еще в дотнете есть средства генерации метаданных, да и кода.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Возможность взаимодействовать с экземпляром за счёт атрибутов. RTTI-сугубо информационная сущность. Поскольку RTTI — это runtime type information, а не например — objects,
Нда. Атрибуты — это средства расширения метаинформации. И атрибуты всегда ассоциируются с метаданными классов/методов. К объектам же они отношения не имеют. Так что рефлекшон и есть информация о типах. Правда от rtti он отличается... тем, что информация доступна не таолько на рантайме, но и во время разработки и даже компиляции.
ГВ>то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно.
Ты снова судишь с позиции С++. А АВК говорит с позиции чистого термина. То что rtti в С++ — это убогий уродец с тобой никто не спорит. Но сама концепция равитая в дургих средах/языках от этого хуже не становится.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.
Да я как бы вообще не употреблял термин rtti. Это вы начали. Я использовал термин "информация о типах". Rtti в С++ уродливо и неполноценно. Хорошими примероми качественной информации о типах я могу назвоть: TLB в COM, и рефлекшон в дотнете и Яве.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Не отмазка, а объяснение. Если я высказался неясно, то нет ничего удивительного в том, что мне пришлось уточнить свою формулировку. Это совершенно нормально. AVK>Ты не уточнил сразу, ты не уточнил даже после того как народ начал тебе объяснять что ты не прав. Ты уточнил только тогда когда у тебя не осталось разумных аргументов. В этом то и проблема
Просто я считаю особенности RTTI-based дизайна очевидными.
AVK>>>Это уже демагогия. Естественно что код, использующий рефлекшен знает что работать он будет таки с классами, а не бог знает с чем. Но не более того. Все остальное пустопорожний треп и попытка перевести спор на терминологию. ГВ>>Что-что? Ты вроде бы говорил о "неизвестных" типах данных, и я указал тебе на ошибку, поскольку дотнетовские типы для дотнетовских же программ известны. AVK>Хорошо, уточню формулировку — неизвестных типов дотнета.
OK, но откуда они там возьмутся? Либо это дотнетовские, а значит — известные типы, либо — не-дотнетовские, а значит — неизвестные типы. Другое дело, что на момент трансляции модуля могут быть неизвестны конкретные дотнетовские типы, которые окажутся на месте аргументов метода, например.
ГВ>>Вот чтобы не выглядело как попытка выкрутиться, я и объясняю то значение термина и те специфические аспекты, на которые я опираюсь в рассуждениях. AVK>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.
Знаешь, я вот думаю сейчас, а не поспешно ли я признал, что reflection и rtti — разные вещи...
ГВ>>Кроме того, RTTI-based по-любому сохраняет свои недост..., тьфу, чёрт, характерные черты. AVK>Спорить о вкусах устриц можно только с теми кто их ел, я все больше убеждаюсь в этом.
Похоже, мы спорим не о вкусе, а об усваиваемости, что можно делать и не поедая устриц. Тем более — в огромных количествах.
AVK>>>
AVK>>>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.
AVK>>>Где тут про какие то особенности или термины? ГВ>>А речь в сообщении шла не о C++? Хм. Очень интересно. Поскольку я всё-таки склонен считать, что речь Влада шла о C++, то я и вспомнил об RTTI, AVK>Речь шла, смотри название топика, о C# и его особенностях по сравнению с С++. И Влад указал на то что фатальным недостатком плюсов является отсутствие аналога рефлекшена. Опять же — можешь у него переспросить что именно он имел ввиду, если мне не веришь.
Угу, дальше он упомянул о глобальном "недостатке" C++ и ввязался я, поскольку подобных утверждений не люблю.
AVK>>>Что же касается "имелись ввиду только ситуации, в которых программа начинает анализировать свой сосбственный состав" то это единственное для чего можно использовать рефлекшен. Т.е. твое утверждение опять же эквивалентно тому что использование рефлекшена означает кривой дизайн. ГВ>>Так или иначе, но все недостатки (sic! — характерные черты) присущие подходу с анализом типов — остаются на месте. Что, if-ы пропадают? Так нет ведь. Онипросто могут быть скрыты, как например в COM. AVK>В общем спор с тобой начинает терять интерес, поскольку от аргументов ты скатываешься к жонглированию понятиями, переводом спора на другие темы и прочими демагогическими приемами. Вот попробуй сам описать связь между моей цитатой и твоим ответом. Я уловить не смог.
Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн". Я, в свою очередь, отказываюсь от подобной категоричности, смягчая её ("Так или иначе"), поскольку по крайней мере на данный момент с этим не согласен. Дальше, поскольку я не хочу обобщать, то просто игнорирую "наезд" и снова повторяю характерные черты RTTI-based-дизайна, поскольку они могут присутствовать при использовании информации из reflection. Т.е. я просто смягчаю категоричность, которую ты мне упорно навязываешь и пытаюсь обратить твоё внимание на очевидный, ИМХО, факт.
ГВ>>Я не буду утверждать, что использование рефлекшена — однозначно кривой дизайн. Есть задачи (например, — технологические, упомянутые выше), для которых он вполне адекватен. AVK>То есть, памятуя о контексте твоего высказывания, ты все таки не прав.
Хех, если с использованием reflection можно добиться чистого LSP-compliant, то Reflection <> RTTI, если нельзя, то увы: Reflection=RTTI и я ошибся, сказав, что это разные вещи.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Вам обоим не кажется, что прочтение одной книжки еще не дает права считать себя экспертом в некоторой оболасти?
Нет не считаю. Но практика показывает что эта книга оочень сильно поднимает уровень.
VD>Еще раз повторсь, что С++ я знаю. И уж точно я знаю его настолько, чтобы иметь право выносить свои суждения об этом зяыке.
Я тоже повторюсь интересно почему движок человека с 10 летним опытом работы на С++ единогласно пошол лесом против моего? Единственное обьяснение которое приходит на ум это то что работать с моим движком почти также просто как с C#. (Я вобще предлагал на шарпе но начальство не согласилось)
Причем когда стоит вопрос Что? все лушают его, когда он превращается в Как? то меня.
VD>Попадется — погляжу. Но искать специально точно не буду. Не верится мне, что можно открыть америку в ванной.
Можно.
К стати на счет авторитетов
Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.
Scott Meyers
Что нового можно сказать о языке С++, Оказывается, очень много.
John Vlissides
Современное проектирование на С++ — важная книга. По существу, "обобщенные шаблоны", или "шаблонные шаблоны", в ней представлены как новый мощный метод гибкого проектирования на языке С++ — новый способ комбинирования шаблонных классов и шаблонов поектирования, о котором мы и мечтать не могли. Если вы проектируете и программируете на языке С++, вам следует прочесть эту книгу. Очень рекомендую...
Herb Sutter
ЗЫ книга из серии C++ In-Depth
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
ГВ>>>>Custom-атрибуты автоматически добавляются? AVK>>>А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения. ГВ>>Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо... AVK>Какой библиотеки?
Библиотеки Framework-а.
AVK>Речь не о данных библиотеки,
Естественно. Даже не о данных, а об алгоритмах.
AVK>а о данных среды исполнения. Естественно что они содержат ровно тот набор, который необходим для функционирования дотнета. Если тебе этого недостаточно то можно метаданные расширить при помощи атрибутов. Уж сколько раз твердили миру — рантайм дотнета это не набор библиотечек как в С++, это совершенно особая сущность, неотделимая от понятия программирования в дотнете и от его языков.
Да я и не опровергаю этого.
ГВ>>Т.е., атрибут является носителем ссылки на тип (вероятно — имени класса), т.е. — на совокупность методов и данных. В определённом смысле — класс как класс. Кстати, в дальнейшем ты продемонстрировал пример вполне себе даже LSP-compliant решения. Недостаток один — атрибуа может не оказаться. AVK>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.
Поздравляю. Это и есть первейший признак RTTI-based дизайна. "Если есть нечто, влияющее на алгоритм..." И это ты называешь "грамотным дизайном"? По идее алгоритм всегда работает штатно, выполняясь на адаптированных для него сущностях. Да, отдельные сегменты могут варьироваться в зависимости от сущностей, но эти сегменты предоставляются самими сущностями (см. — виртуальные функции). Но сам факт выполнения этих сегментов не зависит от характера сущности или же, в случае, если он не нужен, может оптимизироваться компилятором.
Бесспорно, почти то же самое можно сделать с помощью атрибутов, но есть два соображения, по которым и появляется это "почти".
1. Атрибуты могут быть применены, но они не могут быть обязательно применены (если не подмешивается наследование от класса, у которого определён атрибут) что всегда должно влечь за собой условность (признак RTTI-based-дизайна) в их обработке.
2. Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...
Хммм... получается, что...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Ваши нагромождения шаблонов превращают плюсы в птичий язык.
Ну, это ты зря. Если шаблонами пользоваться умело и по месту, то они очень даже хорошо читаются. Вот простой пример из шустрика:
template <class SType>
void __fastcall QuickSort(SType *item, int left, int right)
{
int i, j;
SType center;
SType x;
i = left;
j = right;
center = item[(left + right) 2];
while(i <= j)
{
while (item[i] < center && i < right)
i++;
while (item[j] > center && j > left)
j--;
if (i<=j){
x = item[i];
item[i] = item[j];
item[j] = x;
i++;
j--;
}
}
if(left < j)
QuickSort(item, left, j);
if(right > i)
QuickSort(item, i, right);
}
А вот аналогичный код на Шарпе:
static void QuickSortInt(int[] item, int left, int right)
{
int i, j;
int center;
int x;
i = left;
j = right;
center = item[(left + right) 2];
while(i <= j)
{
while (item[i] < center && i < right)
i++;
while (item[j] > center && j > left)
j--;
if (i<=j){
x = item[i];
item[i] = item[j];
item[j] = x;
i++;
j--;
}
}
if(left < j)
QuickSort(item, left, j);
if(right > i)
QuickSort(item, i, right);
}
Как видишь, разницы почти нет. Так что шаблонный код может быть таким же читабельным как и обычный. За-то универсальность такого кода куда выше.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sergey, Вы писали:
S>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны? S>Я ж не утверждаю, что к синтаксису дельфи привык, хотя около года пришлось с этой бякой поработать.
Я тебе скажу так. Хотя синтаксис шаблонов в С++ меня полностью устраивает. Но в общем и целом я согласен с АВК. Читать исходники на С++ намного сложнее чем на Шарпе. А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.
PS
На плюсах последий раз неделю назад. Вообще написал на них радимых кучу кода. А читать приходилось вообще ороменные листинги.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным? ГВ>>Что ты подразумеваешь под "обычным"? VD>То чем занимашся ты. Долбление кода для решения любой задачи.
Как интересно. А я-то думал, что ты скажешь что-то вроде: "императивное программирование". Ну что же ты...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Возможность взаимодействовать с экземпляром за счёт атрибутов. RTTI-сугубо информационная сущность. Поскольку RTTI — это runtime type information, а не например — objects, VD>Нда. Атрибуты — это средства расширения метаинформации. И атрибуты всегда ассоциируются с метаданными классов/методов. К объектам же они отношения не имеют.
Да ну?
VD>Так что рефлекшон и есть информация о типах. Правда от rtti он отличается... тем, что информация доступна не таолько на рантайме, но и во время разработки и даже компиляции.
Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...
То, что информация о типах доступна в design-time говорит только о развитости среды и относительной легкодоступности этой информации. Ну это как бы и очевидно.
С другой стороны, reflection имеет ещё кучу отличий от rtti. Хотя бы в том, что у него можно спросить не только имя типа.
ГВ>>то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно. VD>Ты снова судишь с позиции С++. А АВК говорит с позиции чистого термина. То что rtti в С++ — это убогий уродец с тобой никто не спорит. Но сама концепция равитая в дургих средах/языках от этого хуже не становится.
Может быть и так. Но от свойственных ей недостатков (sorry — особенностей ) как оверхед (всегда) + ненадёжность (почти всегда) она от этого не избавляется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Именно, а компьютерный "абстрактный объект" всегда представляется чем-то конкретным. И уж точно не " = 0", если речь идёт о работающем объекте.
VD>Не прикидывайся. Речь идет о любом (некотором) объекте.
Даже "любой" объект обязан что-то делать, чтобы вместо вызовов его методов не получались сплошные throw.
ГВ>>С чего ты взял, что я критикую подход всего лишь "на основании того, что в моём любимом языке..."? Если бы всё было в этом подходе "шоколадно", то JIT-компиляция не потребовалась бы. А критиковали его ещё очень давно. С тех пор, как Lisp появился.
VD>С того, что о дотнете ты слышал краем уха. Если бы это было не так, то как минимум ты не говорил бы о JIT-компиляции. Так как она никакого отношения к рефлекшону не имеет.
Да, подловил, извини, я не прав. Я имел ввиду оптимизацию исполняемого кода в зависимости от условий его исполнения. Естественно — это только составная часть .Net-JIT-а.
С другой стороны — как бы это можно было делать анализ условий выполенения, не имея рефлективной информации? Не подскажешь? Это к твоей посылке о том, что "она никакого отношения к рефлекшону не имеет".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да ну?
Ну, да.
ГВ>Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...
Он использует отладочную БД. Можешь обвыключаться rtti, а он все равно будет работать.
ГВ>То, что информация о типах доступна в design-time говорит только о развитости среды и относительной легкодоступности этой информации. Ну это как бы и очевидно.
Ага. В общем, оно говорит о грамотной реализации и удобстве в использовании.
ГВ>Может быть и так. Но от свойственных ей недостатков (sorry — особенностей ) как оверхед (всегда)
Оверхэд есть при любой интерпретации. Все твои предложения по замене рефлекшона строились на том, что ты изобретал свою метаинформацию и анализировал ее. Это не будет быстрее чем анализ штантной метаинформации.
ГВ>+ ненадёжность (почти всегда) она от этого не избавляется.
Ну, а вот это твое глубокое заблуждение. Практика показывает обратное. Решения реализованные на метаинформации обычно надежнее лобового кодирования. Ты кстати тоже ратуя за шаблоны и виртуальные методы кланишь к некому универсальному решинию на базе метаинформации. Но ты почему-то считаешь, что такая информация не зашитая в код приводит к каким-то там проблемам. А это не так. Анализ в рантайме сам по себе ненадежным быть не может.
В общем, борость с метаинформацией и алгоритмами ее использующими так же бессмысленно как нелюбить Пушкина в нашей стране.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Даже "любой" объект обязан что-то делать, чтобы вместо вызовов его методов не получались сплошные throw.
Попробуй еще раз прочесть о чем идет речь...
ГВ>Да, подловил, извини, я не прав. Я имел ввиду оптимизацию исполняемого кода в зависимости от условий его исполнения. Естественно — это только составная часть .Net-JIT-а.
Эти оптимизации никак не влияют на рабту рефлекшона. Рефлекшон ссылается на слоты, а как в эти слоты попадает машинный код и какая обработка осуществляется при его создании/чтении уже десятый вопрос. Даже если вызов метода будет соптимизирован все равно вся информация о нем останется в метаданных и ею можно бдет воспользоваться. Можно будет даже вызвать этот метод динамически (хотя будет вызван не инлайн дубликат).
ГВ>С другой стороны — как бы это можно было делать анализ условий выполенения, не имея рефлективной информации? Не подскажешь? Это к твоей посылке о том, что "она никакого отношения к рефлекшону не имеет".
Спакойно. Общую идею на счет методов я тебе поведал. Метаинфомация же лежит в специальной псевдо-реляционной структуре и есть апи ее четения. Если из кода обратиться к решлекшону, то код будет содержать вызвы этого апи. При этом совершенно все равно будет ли этот код пJIT-ится или будет всят прекомпилированный код. Да даже если будет происходить интерпретация все равно ронвным счетом ничего не изменится.
ЗЫ
Вообще, я не пойму зачем бароться с алгоритмами построенными на базе анализа метаинформации. В базах данных ее нарошно придумывают и хранят в системных таблицах. Компиляторы строят ее для автоматизации процесса кодирования. Что же плохого в том, что и код может иметь самоописание?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>Ерунда это все. Если ты не хочешь чтобы модифицировали то закрывай методы, которые модифицируют содержимое, делай их internal. Так значительно понятнее для чтения и контроль проще.
Это не ерунда. Это фундаментальная проблема дизайна этих системи. Их не так много.
Еще раз: нет способа закрыть методы!
Ну вот смотри: Есть у нас класс Date. У него есть как геттеры, так и сеттеры. Если ты сделашь его сеттеры интернал, то он будет практически иммутабл. И что дальше? Где ты собрался его использовать? В каждой сборке будет свой класс Date? Хорошо, сделаем два класса Date общего назначения. Один будет immutable, другой mutable. Для того, чтобы можно было хранить внутри mutable (мы-то сами собираемся его менять!), а отдавать наружу ссылку на immutable, нам придется унаследовать Date от ConstDate. Хорошо, для дат это еще может проконать, т.к. на практике никто не собирается наследоваться от даты. А как только соберется, он сразу огребет проблемы. Потому что сразу потребуется опять два класса, при этом совместимость сссылок должна быть вот такой:
Ну что же ты... 
