Здравствуйте, VladD2, Вы писали:
VD>В смысле статический или динамический?
Обьясните мне, что подразумевается под статическим полиморфизмом, а что под динамическим?
Я знаю только ad-hoc и параметрический полиморфизмы.
ad-hoc — это перегрузка(overloading) и то, что обычно понимается под полиморфизмом в С++.
parametric — это то, что в функциональных языках понимается под полиморфизмом.
Шаблоны в С++ — это подобие параметрического полиморфизма.
Здравствуйте, prVovik, Вы писали:
Q>>Большая. Потому что выдумать что-то новое нелегко, проще адаптировать чужие идеи под свои нужды. V>И что с того?
Да ничего. Дебильный спор какой-то. Я говорю, что есть одна первоначальная идея, которая породила несколько своих вариаций, а мне говорят — какая разница что появилось первым. Чувствую, скоро на замечание, что сборщик мусора впервые появился в Лиспе, буду получать тот же ответ.
V>Повторяю еще раз. Шаблоны в С++ нужны для манипуляции типами. Ты говоришь, что шаблоны в лиспе лучше, чем шаблоны в С++. Из этого сравнения следует вывод, что шаблоны лиспа лучше манипулируют типами, чем шаблоны С++. Но в лиспе нет типов!!! Следовательно, само сравнение шаблонов С++ и лиспа БРЕДОВОЕ! Это разные, несравнимые вещи.
Да блин. Основное предназначение шаблонов — создавать новые функции и классы с похожей функциональностью на основе параметров. Причем параметрами могут быть не только другие классы, но и константы. Макросы в Лиспе предназначены абсолютно для того же — для того, чтобы создавать куски кода с похожей функциональностью на основе параметров — функций, костант, кусков Лисповского кода. Если ты не видишь здесь никакой аналогии, то спорить не о чем.
Здравствуйте, prVovik, Вы писали:
Q>>Бред какой-то. Типа, если в Лиспе нет оператора for, то он не может покрыть возможностей С++? Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны. V>Повторяю еще раз.
Ну да, повторенье мать учения, и все такое...
V> Шаблоны в С++ нужны для манипуляции типами.
Спорно.
V> Ты говоришь, что шаблоны в лиспе лучше, чем шаблоны в С++. Из этого сравнения следует вывод, что шаблоны лиспа лучше манипулируют типами, чем шаблоны С++.
Тем более спорно. Вывод опирается на ложную посылку.
V> Но в лиспе нет типов!!!
А это уже смешно. Динамическая типизация не предполагает отсутствия типов. Другими словами, "в лиспе есть типы!!!"
V> Следовательно, само сравнение шаблонов С++ и лиспа БРЕДОВОЕ!
Вывод опирается на две БРЕДОВЫЕ посылки. Кстати, использование КАПИТАЛИЗАЦИИ воспринимается как КРИК, это не вежливо.
V>Это разные, несравнимые вещи.
Спорно. Вместо повторения советую переформулировать. Может вы и умную вещь придумали, да больно мудрено, не поймут вас люди, смеятся над вами будут.
Здравствуйте, Курилка, Вы писали:
К>Вот возник вопрос: К>в ФЯ есть полиморфизм типов, что имхо есть очень близко к шаблонам C++. Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ? К>Заранее сенкс за любую инфу!
Когда речь идет о полиморфизме, обыкновенно речь идет о полиморфном вызове функции (метода). Поговорим об этом подробнее. Можно выделить два вида полиморфных функций.
1) Функция ведет себя одинаково с аргументами всех допустимых типов (пример: тип аргумента — абстрактный базовый класс/интерфейс, или функция шаблонная).
2) Функция ведет себя по разному для аргументов разных типов (пример — виртуальная функция/метод перекрытая в подклассах полиморфна по неявному аргументу — объекту класса).
Поговорим об обоих видах полиморфных вызовов для ФЯ с системой типов Хиндли-Милнера/Майкрофта, на примере языков Хаскель и Clean.
1) Существует два способа. Первый — параметрические типы (аналог шаблонов), и второй — АДТ (абстрактные типы данных, ближе всего к интерфейсам). Вроде как все знакомо.
2) А вот здесь начинается самое интересное. Во-первых, для каждого типа (класса), соответствующего АДТ (реализующего интерфейс) надо явно указать набор функций, которые реализуют АДТ. Функции могут быть совершенно произвольными, в частности две разных реализации АДТ могут вообще говоря иметь пересекающийся набор функций. Что прикольно.
А во вторых, при разрешении полиморфного вызова учитываются не только типы, но и значения аргументов (в "обычных" языках — только типы). Причем, в разрешении вызова принимаются во внимание все аргументы (а не только тип неявного аргумента виртуальной функции — объект). Это самое главное отличие полиморфизма ФЯ от обычных языков.
Что это дает? Помните double dispatch? В ФЯ нет такого понятия, так как любой вызов диспетчеризуется по всем аргументам, это предоставляется средой. То, что значения могут быть частью сигнатуры, позволяет избежать создания новых типов (классов) в тех случаях, когда требуется полиморфный вызов. В результате, целый ряд паттернов, известных в ООП, становится тривиальными или просто нивидимыми в ФЯ (http://c2.com/cgi/wiki?DesignPatternsInDynamicProgramming). Наиболее наглядный пример — реализация КА. Примеры я приведу на Erlang, на Хаскеле с Clean будет примерно то же самое.
Функция switch будет полиморфна по двум аргументам (c маленькой буквы — значения, с большой — переменные).
switch( { state_A, Data }, msg_to_B ) -> { state_B, a_to_b( Data ) };
switch( { state_A, Data }, msg_to_C ) -> { state_C, a_to_C( Data ) };
Более натурально то же самое записать так, группируя функции перехода из одного состояния в одну (применяя pattern matching — основной инструмент полиморфизма ФЯ, отсутствующий в ИЯ). Т. е. мы получим по одному определению функции на каждое состояние:
switch( { state_A, Data }, Message ) ->
case Message of
msg_to_B -> { state_B, a_to_b( Data ) };
msg_to_C -> { state_C, a_to_C( Data ) };
end;
В чем здесь отличие от реализации КА на С++ или Java? То, что самая прямолинейная реализация КА будет самой правильной, т. е. соответствующий паттерн невидим. Запись КА в таком виде близка к определению КА, т. е. меньше семантическая разница между задачей и реализацией. С другой стороны, мы не обязаны привязывать "методы" switch и a_to_b к классу состояния, что дает нам гораздо больше свободы — система не так сильно связна и менее хрупка. Часть функций вида a_to_b может оперировать с объектом Data одного типа, часть состояний могут иметь данные разных типов — и мы не будем иметь никаких проблем с постоением грамотной объектной модели. Здесь это просто не нужно — вызовы и так полиморфны, причем во время выполнения.
Итак, К>Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ?
В свете вышесказанного — никакой. Все одинаково далеки.
Здравствуйте, Nick_, Вы писали:
N_>Обьясните мне, что подразумевается под статическим полиморфизмом, а что под динамическим?
Статический когда выбор конкретного варианта осуществляется компилятором (перегрузка и т.п.) и динамический кодга конкретный вариант выбирается в рантайме на базе динамического выбора.
N_>Я знаю только ad-hoc и параметрический полиморфизмы.
Не думаю, что этот термин реально прижился. Не все из Википедии нужно брать на вооружении.
N_>ad-hoc — это перегрузка(overloading) и то, что обычно понимается под полиморфизмом в С++. N_>parametric — это то, что в функциональных языках понимается под полиморфизмом. N_>Шаблоны в С++ — это подобие параметрического полиморфизма.
Это все не типизация. Это общие разрозненные слова. Реально имет значение смысл полиморфизма: создание универсального кода (процедур, функций, методов) или типов, т.е. так чтобы код и типы можно было абстрагировать от конкретных используемых в них типов.
Ну, а дальше можно выделить два подкласса — это статический полиморфизм и динамический. Динамический требует выбора в рантайме, статический ведет к генерации множества вопложений полиморфного кода и типов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Но специализация необязательна. Шаблоны же специализируются не по желанию, а по необходимости и в этом значительно отличаются от полиморфных функций.
Что ты понимашь под специализацией?
Q>И язык системного программирования не С++, а С.
С++ логическое развите С. Все его возможности С++ включает. С предпочитается только если нужно переносить код на экзотические платформы. Ну, и отдельными фанатами. В общем, С++ от наличия С не становится не перестает быть системым языком.
Q>Поскольку Лисп изучается во многих западных университетах, то весьма вероятно, что идея шаблонов возникла не на пустом месте,
Идея шаблонов была в АДА (если не ошибаюсь) и об этом писал Страуступ. А то что что-то где-то изучается еще не значит что оно служит прототипом всему остальному.
Q> а по аналогии с Лиспом.
А зачем такие натянутые аналогии?
Препроцессор OCaml'a тоже не на пустом месте возник. Люди видят насколько полезны макросы и пытаются внедрить их в другие языки.
На примере того же С/С++ люди скорее видят вред макросов. Я бы не называл макросами то что проходит синтаксическую обработку. Иначе возникает путанница.
Q>Для Лиспа существуют компиляторы.
Ага. Вот только толку с них никакого. И суть языка от этого не меняется. Или продолжается интерпритация или начинаются ограничения.
Q> Так что рантайм и компайлтайм там разграничены.
Что-то не заметно.
Q> Никто не запрещает естесвенно пользоваться интерпретатором, но для эффективности стоит программы компилировать.
Да нет там никакой эффективности. Суть языка интерпретаторная. Не может быть быстрым нетипизированный код заточенный на работу со связанными списками.
VD>>Очередное преувеличение. Аналогично моожно сделать обратное заявление. А что? Попробуй сделать типизированную конструкцию на Лиспе?
Q>Лисп нетипизированный язык, поэтому предложение сделать типизированую конструкцию бессмысленно.
То есть говорить об отсуствии чего-то в Лиспе бессмиысленно. А о незаточенности С++ подо что-то нормально? Еще раз повторю свою мысль. Заявление об убогости шаблонов С++ провакациооно и неразумно. Они прекрасно решают поставленную перед ними задачу, и имеют массу приемуществ перед другими подходмаи. Эдак все что тебе не нравится можно назвать убогим. По мне так сам Лис убог. Что-же теперь?
Q>Это в С++ криво и натянуто, а в Лиспе нормально.
Ага. А мужики то и не знают. (с)
Q> Может написать макрос или понять его не так уж легко,
Все. Достаточно. Это и называется убого!
Q> но пользоваться им можно без проблем,
Зашибись. Что нельзя написать на С++? А что нельзя написать на ассемблере? Твоя фраза изумительно к ним подожид. Может написать что-то на ассемблере или понять его не так уж и легко, но пользоваться им можно без проблем. Не находиш что от замены Лисап на Асм ничего не изменилось? Такие рассуждения бессмысленны.
Q> поскольку это выглядит как вызов обычной функции.
Ну, да. А вызов С++-ного кода выглядит вулгарно и неприлично.
VD>>Честно говоря Лисп с его миллионом скобочек меня вводит в состояние гипноза.
Q>Это дело привычки.
К ассмблеру тоже можно привыкнуть. Вопрос тольк нужно ли?
Q>А если есть 2 вложенных while?
Ты говорил о невозможности. Ну, да и это решается если потрахаться.
Q>Опять же, дело привычки.
Опять же с.м. выше.
Q>Хм. макросы обрабатываются на этапе компиляции программы, поэтому замедлять Лисп они врядли могут.
Его замедлять и не нужно. Медленней уже почти некуда.
Q>Почему же унизить?
Ты сейчас ссам с собой разговариваешь? Я незнаю зачем сравнивать совершенно разные вещи испоьзуя эпитеты вроде "примитивнее".
Q> Если я скажу, что в С++ поддержка списков и деревьев на уровне языка примитивная, я его унижу?
Да. Правдой было бы сказать что ее вообще нет. Все списки пишутся на этом языке. Использование же слов вроде примитивные, вульгарные нужно только для того чтобы унизить чьи-то чувства. Я не поборник С++, но и я чувствую неспроведливось в этих действиях.
Q> Я вижу явные аналогии между макросами и шаблонами и думаю
Аналогии не могут использоваться при доказательстве (и темболее при обвинении). Ими можно только иллюстрировать некое описание. Иначе такое доказательство начинает называться демагогией. Так что давай без анлогий. Темболее таких долеких.
Q>, что последние были придуманы под влиянием Лиспа.
Это утверждение как миниум спорно.
Q> Но как не извращайся в С++ выше головы не прыгнешь. Лисп уникален в том смысле, что позволяет модифицировать свой код и писатели макросов этим активно пользуются. В С++ возможны только самые примитивные операции с кодом типа Find&Replace и поэтому макросы-шаблоны там автоматически будут более примитивными. В OCaml придумали кое-что попродвинутей, кстати.
Еще раз повторюсь, что шаблоны в С++ не являются чистыми макросами. Это фича для обобщенного программирования. Как ее можно сравнивать с макросами из нетипизированного интерпретируемого языка я вообще не понимаю. Что же касается возможностей, то дай бог всем ФЯ иметь такие возможности как у С++. Этому бы языку устранить грабли, цены бы ему не было бы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Да ничего. Дебильный спор какой-то. Я говорю, что есть одна первоначальная идея, которая породила несколько своих вариаций, а мне говорят — какая разница что появилось первым. Чувствую, скоро на замечание, что сборщик мусора впервые появился в Лиспе, буду получать тот же ответ.
Мне действительно по барабану, что и где появлялось первым. Порох, например, китайци первыми придумали, и что теперь всем остальным не использовать огнестрельное оружие?
Q>Да блин. Основное предназначение шаблонов — создавать новые функции и классы с похожей функциональностью на основе параметров.
А зачем надо генерировать функции с похожей функциональностью? Разве нельзя обойтись динамическим полиформизмом? Ведь он и был придуман ради того, чтобы одни и теже функции могли вести себя немного по разному, в зависимости от переданных параметров? Сделать полиморфный вариант STL — это совершенно не проблема. Например, для делфи есть такой полиморфный аналог STL. Для С также существовала масса нетипизированных библиотек, содержащих реализации списков, множеств и пр. структур данных, отличительной особенностью которых являлось то, что они хранили свои элементы, как нетипизированные указатели (void*). Но подобные полиморфные решения c динамической типизацией обладают двумя серьезными недостатками:
1) Производительность. Компилятор не в состоянии проводить агрессивную оптимизацию, подставлять методы (inline). Все проверки безопасности могут быть выполнены только во время работы программы и, следовательно, могут существенно повлиять на ее производительность.
2) Типобезопасность. Возможные ошибки некорректного использования динамически полиморфного кода могут всплыть только на этапе выполнения программы (во время демонстрации её заказчику ). Компилятор не в состоянии тут ничем помочь, так как он не может применить статический контроль типизации.
Решением этих проблем может стать отказ от универсального полиморфного кода и переход к статически типизированному. Именно для этого и служат шаблоны в С++!!!! Именно для создания статически типизированного кода!!! Поэтому я и говорил, что шаблоны С++ оперируют типами. Или другими словами, шаблоны в С++ — это механизм организации статического полиморфизма. Это узкоспециализированный механизм, который АБСОЛЮТНО не предназначен для генерации кода. Из-зи этого совершенно не имеет смысла сравнивать лисповые макросы с шаблонами.
А для генерации кода в С/С++ имеется совершенно другое средство: препроцессор. Вот с ним делать сравнение абсолютно корректно, и я согласен с тем, что в С/С++ препроцессор — это убожество.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Nick_, Вы писали:
VD>Статический когда выбор конкретного варианта осуществляется компилятором (перегрузка и т.п.) и динамический кодга конкретный вариант выбирается в рантайме на базе динамического выбора.
Я не вижу тут разницы. Если компилятор С++ знает тип объекта у которого вызывается виртуальный метод, то он может подставить сразу вызов необходимого метода в обход таблиц виртуальных функций.
В С++ есть четкое деление на "статический" и "динамический" полиморфизмы только потому, что у них различается синтаксис. Если хочешь рантайм поддержку приходится писать x->foo(y);
В функциональных языках если компилятор знает тип аргумета, то вызывает конкретную функцию, если не знает, то это делает рантайм. В обоих случаях вызов записывается одинаково: foo x y
N_>>Я знаю только ad-hoc и параметрический полиморфизмы.
VD>Не думаю, что этот термин реально прижился. Не все из Википедии нужно брать на вооружении.
Может этот термин и не прижился в рядах web программистов, но в рядах ученых он используется.
N_>>ad-hoc — это перегрузка(overloading) и то, что обычно понимается под полиморфизмом в С++. N_>>parametric — это то, что в функциональных языках понимается под полиморфизмом. N_>>Шаблоны в С++ — это подобие параметрического полиморфизма.
VD>Это все не типизация. Это общие разрозненные слова. Реально имет значение смысл полиморфизма: создание универсального кода (процедур, функций, методов) или типов, т.е. так чтобы код и типы можно было абстрагировать от конкретных используемых в них типов.
Сложно формально описать систему типов в функциональных языках. Наверное это проще сделать на примерах.
Я на досуге попробую найти хороший пример на хаскеле.
VD>Ну, а дальше можно выделить два подкласса — это статический полиморфизм и динамический. Динамический требует выбора в рантайме, статический ведет к генерации множества вопложений полиморфного кода и типов.
Здравствуйте, Quintanar, Вы писали:
Q>Да блин. Основное предназначение шаблонов — создавать новые функции и классы с похожей функциональностью на основе параметров. Причем параметрами могут быть не только другие классы, но и константы. Макросы в Лиспе предназначены абсолютно для того же — для того, чтобы создавать куски кода с похожей функциональностью на основе параметров — функций, костант, кусков Лисповского кода. Если ты не видишь здесь никакой аналогии, то спорить не о чем.
Вообще-то шаблоны концептуально задумывались как средство создания обобщенного кода. А уж как макросами ими начали пользоваться от нехватки других средств.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>само сравнение шаблонов С++ и лиспа БРЕДОВОЕ!
Большая просьба, выбирать более мягкие выражения. Этот форум не филиал священных войн. Предупреждаю, что подъвекти с оскорбительным характером будут сноситься в "Священные войны".
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>...АДТ (абстрактные типы данных
Ты хотел сказать АТД (ADT)?
G>А во вторых, при разрешении полиморфного вызова учитываются не только типы, но и значения аргументов (в "обычных" языках — только типы). Причем, в разрешении вызова принимаются во внимание все аргументы (а не только тип неявного аргумента виртуальной функции — объект). Это самое главное отличие полиморфизма ФЯ от обычных языков.
В "обычных языках" это называется мутиметодами. Они кое где реализованы. А кое где реализуются имеющимися средствами.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V> 1) Производительность. Компилятор не в состоянии проводить агрессивную оптимизацию, подставлять методы (inline). Все проверки безопасности могут быть выполнены только во время работы программы и, следовательно, могут существенно повлиять на ее производительность. V> 2) Типобезопасность. Возможные ошибки некорректного использования динамически полиморфного кода могут всплыть только на этапе выполнения программы (во время демонстрации её заказчику ). Компилятор не в состоянии тут ничем помочь, так как он не может применить статический контроль типизации.
Может. В динамически типизированных языках можно вывести типы статически из контекста употребления. Не все, конечно, но во многих местах — можно. Из известных языков, где применяется type inference — JScript .NET (сюрприз!).
V>Решением этих проблем может стать отказ от универсального полиморфного кода и переход к статически типизированному. Именно для этого и служат шаблоны в С++!!!! Именно для создания статически типизированного кода!!! Поэтому я и говорил, что шаблоны С++ оперируют типами. Или другими словами, шаблоны в С++ — это механизм организации статического полиморфизма. Это узкоспециализированный механизм, который АБСОЛЮТНО не предназначен для генерации кода. Из-зи этого совершенно не имеет смысла сравнивать лисповые макросы с шаблонами.
Все гораздо проще. В динамически типизированном языке любая функция — "шаблонная". И любой "класс". Там просто нет нужды в механизме, подобном шаблонам — и так все шаблон, причем работает в рантайме. Поэтому макросы лиспа вроде как нельзя сравнивать с шаблонами С++.
Хотя, если посмотреть книжку Александреску, в которой он жестко надругался над С++ — то очень даже можно и нужно . Там он демонстрирует, что в compile time при помощи шаблонов можно сделать практически все, что угодно — благодаря наличию рекурсии мы имеем вычислительную полноту. Ничего не напоминает? Мне напоминает макросы лисп . Так что ответ не так однозначен.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Спорно. VD>... G>>Тем более спорно. Вывод опирается на ложную посылку.
VD>Т.е. спорно в твоих устах значит бесспорно неверно? Мне кажется слова спорный и ложный синонимами не являются.
Спорный тезис, в моих устах, является ложной посылкой, если используется в качестве посылки. Посылка может являтся либо истинной, либо нет. Промежуточного варианта в логике пока не придумали. Если посылка не является истинной, то она ложная. В таком вот аксепте. Компрене ву?
А вообще, может не будем цепляться к словам? Это оффтоп.
Здравствуйте, Nick_, Вы писали:
N_>Я не вижу тут разницы. Если компилятор С++ знает тип объекта у которого вызывается виртуальный метод, то он может подставить сразу вызов необходимого метода в обход таблиц виртуальных функций.
Причем тут С++ я не знаю. Но сам описанный тобой метод называется спекулятивным устранением виртуальных вызовов. Так что по сути это и есть замена динамического полипорфизма на статический на базе предположения компилятора.
N_>В С++ есть четкое деление на "статический" и "динамический" полиморфизмы только потому, что у них различается синтаксис. Если хочешь рантайм поддержку приходится писать x->foo(y);
Такое деление есть не только в С++. Да и я не о нем говорил. Я говорил в принципе о подходе к реализации. Динамический всегда медленее но универсальнее, а статический пухлее, но шустрее.
N_>В функциональных языках если компилятор знает тип аргумета, то вызывает конкретную функцию, если не знает, то это делает рантайм. В обоих случаях вызов записывается одинаково: foo x y
Это не важно. В любом случае или делаются проверки (выбор) в рантайме, или создаются невидимые воплощения. В С++ тоже тело шаблона одно. Но при воплощении создаются специализированные реализации.
Ты заявлял, что в ФЯ дело осбтоит совершенно иначе. Вот с этим я и не согласен. Все тоже самое. Или компилятор строит статический специализированный кода, или некий универсальный, но с проверкой в рантайме.
N_>Может этот термин и не прижился в рядах web программистов, но в рядах ученых он используется.
Ну, снова. Давай не будем использовать подобные приемы. Не стоит зачислять себя в ряд ученых, а аппонента в ряд веб-программистов.
Этот термин не прижился нигде. Он просто редок.
N_>Я на досуге попробую найти хороший пример на хаскеле.
Мне кажется нужно вообще сделать общую статью о функциональном стиле программирования с кучей примеров на разных языках. Тогда каждый сможет найти язык на котором примеры ему будут понятны, а остальные поймет по аналогии.
Как идея?
VD>>Ну, а дальше можно выделить два подкласса — это статический полиморфизм и динамический. Динамический требует выбора в рантайме, статический ведет к генерации множества вопложений полиморфного кода и типов.
N_>Вот этого не надо. Это дело компилятора.
Я согласен, что оптимальным решенеим было бы переложить выбор типа полиморфизма на компилятор или даже на рантайм вроде Ява-машины или .Net CLR, но к сожалению зачастую это не так. И нужно четко понимать особенности этих двух типов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>...АДТ (абстрактные типы данных
VD>Ты хотел сказать АТД (ADT)?
Я обычно говорю ADT (АДТ) . Что это ты сегодня за мой русский язык взялся?
G>>А во вторых, при разрешении полиморфного вызова учитываются не только типы, но и значения аргументов (в "обычных" языках — только типы). Причем, в разрешении вызова принимаются во внимание все аргументы (а не только тип неявного аргумента виртуальной функции — объект). Это самое главное отличие полиморфизма ФЯ от обычных языков.
VD>В "обычных языках" это называется мутиметодами. Они кое где реализованы.
О как (век живи — век учись)! Пример пожалуйста, особенно "обычного языка", где учитываются значения аргументов при полиморфном вызове в run-time (твой комментарий по правилам русского языка относится ко всему абзацу, а не ко второй половине ).
Только CLOS не надо приводить, ок? Термин "мультиметод" оттуда, и это диалект лиспа
Не думаю, что в списке примеров окажется С#, Java, и даже Smalltalk. Вряд ли это будет такой уж "обычный" язык. Пример, пример в студию. Интересно, и я думаю, не только мне.
VD>А кое где реализуются имеющимися средствами.
Гхм. Имеющееся средство называется double dispatch для случая двух аргументов, я про это упомянул. Реализуется везде, имеющимися средствами, бо дурацкое дело нехитрое. У Мейерса описан еще более извращенный способ. Если ты о чем то другом, то будь любезен, расскажи, интересно. А то не вполне понятна цель твоего ответа — он не слишком информативен — один хитрый ленинский прищур
Здравствуйте, Gaperton, Вы писали:
G> Все гораздо проще. В динамически типизированном языке любая функция — "шаблонная". И любой "класс".
Скорее, полиморфная. Но это уже терминология, так что не важно...
G>Хотя, если посмотреть книжку Александреску, в которой он жестко надругался над С++ — то очень даже можно и нужно . Там он демонстрирует, что в compile time при помощи шаблонов можно сделать практически все, что угодно — благодаря наличию рекурсии мы имеем вычислительную полноту. Ничего не напоминает? Мне напоминает макросы лисп . Так что ответ не так однозначен.
Приведу аналогию. Вот компания Nokia выпустила сотовый телефон в титановом корпусе. Он очень крепкий и, наверное, им можно забивать гвозди. Дак вот, сравнивать этот телефон с молотком мне кажется некорректно, даже несмотря на то, что телефоном в принцепе можно забивать гвозди. .
Понятно, что молотком забивать гвозди проще, но из-за этого у телефона его телефонных качеств не прибавляется и не убавляется .
Я говорю: "А зато, с помощью молотка нельзя звонить". На что мне отвечают:
Бред какой-то... Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны.
V>Приведу аналогию. Вот компания Nokia выпустила сотовый телефон в титановом корпусе. Он очень крепкий и, наверное, им можно забивать гвозди. Дак вот, сравнивать этот телефон с молотком мне кажется некорректно, даже несмотря на то, что телефоном в принцепе можно забивать гвозди. . V>Понятно, что молотком забивать гвозди проще, но из-за этого у телефона его телефонных качеств не прибавляется и не убавляется .
Все аналогии некорректны. Мы не дети, чтобы переходить на яблоки.
V>Я говорю: "А зато, с помощью молотка нельзя звонить". На что мне отвечают: V>
Бред какой-то... Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны.
V>
Правильно тебе отвечают. В лиспе делается все тоже самое, что делается на шаблонах, легко обходясь без понятия шаблона. На шаблонах, при помощи техники Александреску, можно сделать через зад многие вещи, которые делаются на макросах лиспа, и делаются там красиво. Я не понимаю, причем тут "А зато, с помощью молотка нельзя звонить".
Динамическая типизация не предполагает отсутствия типов. Другими словами, "в лиспе есть типы!!!" 
