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

K>>>Современным может быть и чистый функциональный язык, например. Но это не важно.
K>>>Непонятно, кстати, почему слово "современные" Вы ставите в кавычки. Современные без всяких ковычек. Просто тенденция сейчас такая, веянье времени.
AVC>>Ясно, что слово "современный" употребляется здесь в каком-то определенном смысле, потому что и сейчас есть люди, пишущие на Фортране, да и функциональные языки сами по себе — не такая уж новость.
AVC>>Возможно, Ваша ремарка говорит о том, что Вы считаете функциональный подход в целом более современным (прогрессивным?), чем императивный?

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

Действительно, я сопоставил понятия разного уровня, что, наверное, не вполне корректно.
Но, ИМХО, они не "ортогональны" (не сопоставимы?), т.к. функциональное программирование есть разновидность декларативного подхода.
В этом смысле я и упомянул "функциональный подход".

K>Однако "прогрессивный" или "современный" все-таки не синонимы. Если понимать в хронологическом смысле, то, к примеру, чистый функциональный язык по понятным техническим причинам, не может не быть современным, хотя функциональные языки вообще, конечно, не новость. Причем под современным с хронологической точки зрения языком я подразумеваю не используемый в настоящее время, а разработанный и реализованный в настоящее время.

В таком случае, я бы говорил о "новых" языках.
ИМХО, слово "современные" не так однозначно.

K>Понятно, что если говорить о современном только в хронологическом смысле, то разговоры о том, что должно быть в языке для того, чтобы он считался современным довольно странно. Поясняю: новые с хронологической точки зрения языки, появляющиеся в настоящее время создают некоторую конъюнктуру. Можно выделить некоторую общую для большинства из них совокупность черт, которые и позволяют судить о том, соответствует ли новый язык этой самой конъюнктуре или является анахронизмом.

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

K>Вот и все что я имею в виду, говоря о современных и несовременных языках. Надеюсь, что теперь ситуация прояснилась?

Более или менее.
Спасибо, это помогло мне несколько уточнить свои представления.

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

AVC>>Есть и свои противоречия: например, трудновато совместить оптимизацию кода и отладку (оптимизированный код далек от исходного).
WH>Честно говоря вобще невижу смысла смешивать оптимизацию и отладку.

Я бы тоже...
Но меня несколько смущает тот факт, что люди отлаживают одну программу, а используют другую (оптимизированную).
В моем случае это, как правило, встроенные приложения; значение имеет не только "правильность", но и эффективность и т.д.
Вообще, создание хорошего отладчика для меня пока самое темное место. Пока просто подражаю (по мере сил) распространенным отладчикам.

AVC>>Что же касается синтаксического анализа, то частенько "все сделано до нас" (для известных языков).
WH>А для только-что придуманых?

Тогда, конечно, придется самому.

AVC>>Если есть необходимость написать парсер и не хочется писать его методом рекурсивного спуска a-la Wirth (или грамматика не позволяет), то в нашем распоряжении yacc (для LR-грамматик) или CoCo/R(для LL(1)-грамматик; кстати, автор CoCo/R является также автором языков Object Oberon и Оберон-2).
WH>Тут не все так простл. Попробуй ими распарсить тотже C#... Влад пытался использовать CoCo/R но получилось мягко говоря не очень. А что касается всяких yacc'ов то их озвереешь отлаживать и добится от них человекочитаемых сообщений об ошибках.

Та же ситуация с чтением сообщений компилятора Си++ об ошибках в шаблонах (по крайней мере, так было еще недавно).
Вообще так обстоит дело со многими генераторами (самыми разными).

AVC>>А какие есть проблемы с заглядыванием вперед?
WH>LL(1) циифирка 1 о чем говорит?

О заглядывании, конечно.
Просто наличие одной дополнительной переменной ОчереднаяЛексема, ИМХО, не является большой проблемой.

AVC>>Если я пользуюсь генератором парсеров, то я вообще с такой проблемой не сталкиваюсь.
WH> ты только с ней и сталкиваешься... просто ты уже привых укладывать грамматики в прокрустово ложе парсеров.

Да, может быть, что это просто привычка.

AVC>>Если пишу парсер вручную, то заглядывание происходит всего на один символ вперед.
WH>А я могу заглянуть на сколько нужно.

В принципе, Трурль здесь предложил вариант, как это сделать на Обероне, хотя меня этот вариант не вдохновил.
Подобный способ используется и при создании парсеров с помощью YACC, например, при попытке использовать лексемы слева от правила: $0 и т.д.

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

AVC>Интересно, насколько клоны ML могут помочь мне в этих задачах.

Здесь это примерно объяснено.
Why ML/OCaml are good for writing compilers

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

VD>>Согласись это выглядит очень неплохо для встроенных возможностей языка?
S>Ну естественно неплохо! Влад, ты похоже потерял нить рассуждений.

Я? Ты меня с кем-то путаешь.

S>Речь идет о выразимости паттернов в виде конструкций. kan сомневался

Автор: kan
Дата: 26.09.06

в том, что паттерн можно выразить в языке, а уж тем более в библиотеке.

Похоже нить потерял кто-то другой. С этим товарищем все ясно. Он несомненно заблуждается. Мы же в данный момент говорим о замечании Andrei N.Sobchuck

Автор: Andrei N.Sobchuck
Дата: 29.09.06

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

S>Я привел примеры того, как паттерны встраиваются в язык. Ты собственно с чем споришь?

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

S> С тем, что их нужно поддерживать? Или что их нужно поддерживать при помощи Nemerle?

С тем что чем хардкодить подобные решения в язык лучше делать язык более гибким. Я бы был бы очень рад если опыт того саомго Немерле были учтеным МС. В конце концов в самом Немерле ничего в общем-то радикально новго не придумано. Это обобщение опыта кучи народа. Далеко не идеальное обобщение, но все же результат получается более качественным чем у МС где обобщали опыт только ООЯ.

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

S>Ну, в рамках .net 1.0 это пришлось бы делать ровно один раз на каждый тип делегата. Руками.

Да, без дженерико конечно сложно. Хотя возможно если их подерживть на уровне языка.

S>Почему некорректно?

Потому что ты не учитель, а я не ученик.

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

Я табе уже показал кажется, что метапрограммирование для таких задач не требуется. А Хейльсберг не является богом. Он инженер, т.е. человек. И он делает как и мы все ошибки. Ошибки эти незаметы пока ты не видел ничего другого. Но сравнивая решения они становятся отчетливо видны. Вот делегаты, отсуствие дженериков в 1.х и кортежей — это ошибки уменьшающие выразительность языка. Отсюда и необходимость внонитровать довольно примитивные паттерны в язык.

С другой стороны эти ошибки все же более терпимы нежели идеологические промахи Явы. Но Ява пролое оправдение.

S>Ну, вообще-то как раз на 2.0 можно написать один класс. Он, кстати, будет не многим менее удобен в использовании, чем твой вариант на Nemerle.

Напиши, сравним. Увидишь, что выразительных средств нехватает. Дело портят делегаты и остуствие кортежей. Реализация метода Fire() окажется затруднительной. Ведь передать параметры метода делегату в общем случае будет нельзя.

S>Ты очень много говоришь, и очень мало слушаешь.

Синклер, тебе не кажется что подобные переходы на личности не красят тебя лично?

S> В Nemerle встраивать event в язык уже не надо.

Ага. И ничего не мешало МС сделать в Шарпе тоже самое.

VD>>Синклер, ты меня извини, но твой менторский тон мне не нравится. Или убери эту маску гуру, или давай завершим разговор.
S>Только после вас.

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

VD>>Это мелкие детали. По сути это тоже свойство вид сбоку. Тебе уже скзали, что небыло бы никакой разницы если бы вместо этих спец-методов был бы некий интерфейс с думя методами.
S>Я вижу, мои объяснения, что это не тоже самое, не внедряются в кору головного мозга оппонентов.

А должны? Ну, не знаю, я внушения всегда плохо поддавался. На мой взгляд это заблуждения.

S> Ок, зайдем с другого конца: почему бы собственно свойства не выкинуть в пользу некоего интерфейса с двумя методами: set и get? Поясни, пожалуйста, cвою точку зрения.

Потому что они снизят выразительные возожности языка. Тут же я тебе кажется показал, что разницы практически нет.

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

S>Не понял, куда это она уменьшится. Ты не мог бы привести пример, каким образом удастся при помощи лямбды избавиться, к примеру, от AppDomain.AssemblyResolve?

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

События конечо не уйдут, но потребность в них будет уменьшаться.

S>Вот как раз у меня-то с этим все в порядке.

По твоему отношению к другим это не заметно.

VD>>Причем люди могут банально иметь более широкий опыт и тем самым мыслить чуть шире.
S>Пока что я вижу обратный эффект.

Вот это и есть проявление того о чем я тебе говорю.

S> Мне заявляют "чего-то не может быть, потому что я этого не встречал". Очень сомневаюсь, что это признак широты мышления.

А ты не сомневайся. А сомневаясь разбирайся и ищи истину, а не делай надменный вид.

VD>>Ты же не имея этого опыта
S>Очень опять же сомневаюсь, что у тебя есть возможность адекватно оценивать мой опыт.

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

S>Я кстати никаких комментариев о ширине мышления не приводил. Я просто объясняю, с какими ситуациями призван бороться определенный паттерн.

А ты почитай свои письма. Возможно тебе они кажутся наормальными, но мне не очень. Ментроский тон в них откровенно раздражает.

VD>>Хм. Я мог присвоить им nil. Ты тут говорил, что это так плохо.
S>Нет, я не говорил, что nil это плохо. Я говорю, что отсутствие инкапсуляции приводит к тому, что можно банально забыть о том, что ты не единственный субскрайбер или просто опечататься и набрать = вместо +=.

Во как. То есть инкапсуляция должна спосать от опечаток? Браво. И почему же эта самая инкапсуляция не трогает тебе в отношении полей и свойств? Ведь в них тоже вместо += можно поставить случайно = и результат будет иным. К тому же реализованное мной решение не имеет такой проблем.

S> В Дельфи ты всегда был единственным субскрайбером, и поток событий был значительно проще. У тебя просто не было пяти мест вида "OnResize += HandleResize", в каждом из которых ты мог ошибиться. Если ты записал nil, то это быстро станет заметно.

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

VD>>Я согласен, что список событий иногда удобнее. Но его нет проблем создать без хардкода.
S>См. VCL Source. Я уже не помню имена юнитов наизусть, но парни сделали таки без хардкода поддержку множественных подписчиков на состояние датасорсв. Ох там и кода наколбашено...

Это их проблемы. Я тебе привел код работающей реализации.

S>В отдельном языке — да. Кстати, интересно: насколько сложно было бы сделать такие евенты кросс-языковыми? Чтобы в VB.NET по-прежнему можно было бы писать после имени метода handles EventBlaBla?

Проблемы языков не стоит смешивать. ВБ всю жизнь все хардкодил. Ну, и тут не проблема была. А вооще можно было и в ВБ добавить нужные вещи.

Если чесно ВБ и Шарп отличаются очень слабо. Эти отличия доволно косметические. И вобще языки дотнета получаются довольно похожими. Это как раз и есть стледствие того, что очень много высокоуровневых концепций заложено в рантайме. И это, по-моему, не очень хорошо.

S>Это какие например? Я в Delphi архитектурных ошибок не вижу.

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

S> Его недостатки очевидным образом связаны как с ограниченными ресурсами, так и с ограниченным опытом использования.

Ага, так и есть, как, в рочем и с огрниченым опытом авторов.

VD>>К сожалению, насколько я помню, ивенты захардкодили в рантайме дотнета.
S>Совершенно верно. Как и свойства. Свойства, кстати, ведь тоже наверняка можно было бы сделать на уровне библиотеки для языка с метапрограммингом (aka Nemerle)?

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

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

VD>Похоже нить потерял кто-то другой.
А, да, что-то я упустил этот момент.
VD>Мы же в данный момент говорим о замечании Andrei N.Sobchuck

Автор: Andrei N.Sobchuck
Дата: 29.09.06

, о том, что многое можно было бы не хардкодить в язык, а реализовать средствами языка или сделать такие средства язык чтобы некоторые паттерны не имели смысла.
А, я просто понял его утверждение так, что можно было обойтись без event в "обычном" шарпе. Потому, что он использовал только упоминание об интерфейсе, который есть начиная с 1.0, а громоздкость этого решения я продемонстрировал.Это ты уже предложил попросту заменить его другим языком

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

kan>Прошу прощения за невнимательность, конечно Observer.

Вот и мне показалось, что ты говоришь не о паттерне Посетитель.

Мы же вели речь именно о нем. Этот паттерн отличает то, что он пронизывает сразу кучу классов и как бы пенпердикулярен основной задаче решаемой этим самым паттерном. Реализация и сопровождение его весьма не просты. И вот как раз его неполохо можно было бы встроить в язык. И метапрограммирование является отличным средством для этого. Хотя если в языке есть паттерн-матчинг, то необходимость в самом паттерне Посетитель в общем-то нивелируется.

kan>Т.е. это не паттерн Observer из-за того, что асинхронный?

Не понял к чему этот вопрос вообще.

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

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

Думаю, самое простое спросить его самого. Но я понял его слова как скорее претензию к самому Шарпу. Он же поклонник Смолтока где многие подобные вещи прокатывают без расширения зяыка.

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

Как я понял — это был ответ на твой вопрос "как быть с +=".

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


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

VD>Думаю, самое простое спросить его самого.

Я уже просёк, что без дженериков потеряется типизированость этой структуры. Вроде в v.1 не было дженериков, вот и прилепили невесть что.

Отвращение к внесению подобных сущностей в язык у меня осталось

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

К>Этот вопрос уже обсуждался несколько раз на РСДН, а Марк Доминус в своей статье Design patterns of 1972 описал это на мой взгляд довольно подробно. Упомянул он и презентацию Design Patterns in Dynamic Languages Питера Норвига.
К>Основная, на мой взгляд, мысль статьи : паттерны это хорошо, но по сути это костыли, т.к. каждый раз паттерн нужно реализовывать снова и снова.

Возвращаясь ненадолго к этой, уже "остывшей", теме.
Если основная мысль в том, что паттерны — всего-лишь "костыли", и все должно быть включено в язык, то в таком общем виде эта мысль, вероятно, неверна.
Надо учесть, что некоторые паттерны специально созданы для того, что избавиться от слишком большой жесткости языка программирования и привнести дополнительную косвенность.
В качестве примера можно взять паттерны порождения объектов.
Прямое указание класса создаваемого объекта ограничивает гибкость.
Чтобы избежать этого и созданы паттерны порождения объектов.
Т.е. они созданы именно для того, чтобы преодолеть ограничения языка (при создании объекта надо задать класс объекта).

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

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


AVC>Возвращаясь ненадолго к этой, уже "остывшей", теме.
AVC>Если основная мысль в том, что паттерны — всего-лишь "костыли", и все должно быть включено в язык, то в таком общем виде эта мысль, вероятно, неверна.

А теории да.

AVC>Надо учесть, что некоторые паттерны специально созданы для того, что избавиться от слишком большой жесткости языка программирования и привнести дополнительную косвенность.
AVC>В качестве примера можно взять паттерны порождения объектов.
AVC>Прямое указание класса создаваемого объекта ограничивает гибкость.
AVC>Чтобы избежать этого и созданы паттерны порождения объектов.
AVC>Т.е. они созданы именно для того, чтобы преодолеть ограничения языка (при создании объекта надо задать класс объекта).

В динамических языках таких ограничений нет, и практически все паттерны порождающие объекты (и даже классы) реализуются парой строк кода.

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

AVC>>Надо учесть, что некоторые паттерны специально созданы для того, что избавиться от слишком большой жесткости языка программирования и привнести дополнительную косвенность.
AVC>>В качестве примера можно взять паттерны порождения объектов.
AVC>>Прямое указание класса создаваемого объекта ограничивает гибкость.
AVC>>Чтобы избежать этого и созданы паттерны порождения объектов.
AVC>>Т.е. они созданы именно для того, чтобы преодолеть ограничения языка (при создании объекта надо задать класс объекта).

FR>В динамических языках таких ограничений нет, и практически все паттерны порождающие объекты (и даже классы) реализуются парой строк кода.

Ты хочешь сказать, что нет разницы между "приобретением" типа в порождающем паттерне и динамическом языке?
(Маленькое лирическое отступление. Помню старую советскую карикатуру. Две мыши в библиотеке грызут книги. Одна говорит другой: "Не вижу разницы между классикой и современной литературой". )
В языках с динамической типизацией переменная "приобретает" тип, когда ей присваивается значение.
В "порождающих" паттернах происходит ровно то же самое: указатель получает "конкретный" тип, когда начинает указывать на созданный объект.
Вроде, все похоже.
ИМХО, в динамических языках действует именно паттерн (назовем его...э-э... "получение типа от другого уже созданного объекта" или "получил тип сам — передай другому").

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


FR>>В динамических языках таких ограничений нет, и практически все паттерны порождающие объекты (и даже классы) реализуются парой строк кода.

AVC>Ты хочешь сказать, что нет разницы между "приобретением" типа в порождающем паттерне и динамическом языке?

Интересно в таком направлении не думал, но похоже так оно и есть
Я просто имел в виду что в динамике этот паттерн практически встроен.

AVC>(Маленькое лирическое отступление. Помню старую советскую карикатуру. Две мыши в библиотеке грызут книги. Одна говорит другой: "Не вижу разницы между классикой и современной литературой". )
AVC>В языках с динамической типизацией переменная "приобретает" тип, когда ей присваивается значение.
AVC>В "порождающих" паттернах происходит ровно то же самое: указатель получает "конкретный" тип, когда начинает указывать на созданный объект.
AVC>Вроде, все похоже.
AVC>ИМХО, в динамических языках действует именно паттерн (назовем его...э-э... "получение типа от другого уже созданного объекта" или "получил тип сам — передай другому").

Угу действует, и поэтому твой пример с порождающими паттернами не верен

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

AVC>Возвращаясь ненадолго к этой, уже "остывшей", теме.
AVC>Если основная мысль в том, что паттерны — всего-лишь "костыли", и все должно быть включено в язык, то в таком общем виде эта мысль, вероятно, неверна.
Откуда ты взял выделенное, интересно?
Или ты не видишь разницы между расширяемым языком и языком, в который включено всё, что только можно?

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

AVC>>(Маленькое лирическое отступление. Помню старую советскую карикатуру. Две мыши в библиотеке грызут книги. Одна говорит другой: "Не вижу разницы между классикой и современной литературой". )
AVC>>В языках с динамической типизацией переменная "приобретает" тип, когда ей присваивается значение.
AVC>>В "порождающих" паттернах происходит ровно то же самое: указатель получает "конкретный" тип, когда начинает указывать на созданный объект.
AVC>>Вроде, все похоже.
AVC>>ИМХО, в динамических языках действует именно паттерн (назовем его...э-э... "получение типа от другого уже созданного объекта" или "получил тип сам — передай другому").

FR>Угу действует, и поэтому твой пример с порождающими паттернами не верен

Отнюдь.
Просто я спросонок выражаюсь по утреннему туманно.
Я как раз хотел сказать, что в этом пункте (порождение объектов) между динамическими и статическими языками нет принципиальной разницы.
В динамических языках какой-нибудь оператор x = "Hello!" ничуть не лучше скрывает тип, чем в Си++ p = new String("Hello!").
В динамическом языке, чтобы сохранить гибкость при порождении объекта, тебе точно также придется прибегнуть к паттерну.

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


AVC>Отнюдь.
AVC>Просто я спросонок выражаюсь по утреннему туманно.
AVC>Я как раз хотел сказать, что в этом пункте (порождение объектов) между динамическими и статическими языками нет принципиальной разницы.
AVC>В динамических языках какой-нибудь оператор x = "Hello!" ничуть не лучше скрывает тип, чем в Си++ p = new String("Hello!").
AVC>В динамическом языке, чтобы сохранить гибкость при порождении объекта, тебе точно также придется прибегнуть к паттерну.

Который выродится просто в строку кода на этом динамическом языке.

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

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

AVC>>В динамическом языке, чтобы сохранить гибкость при порождении объекта, тебе точно также придется прибегнуть к паттерну.

FR>Который выродится просто в строку кода на этом динамическом языке.

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

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

AVC>>>В динамическом языке, чтобы сохранить гибкость при порождении объекта, тебе точно также придется прибегнуть к паттерну.

FR>>Который выродится просто в строку кода на этом динамическом языке.

К>Не факт.
К>Господа — вы бы хоть договорились о том, какой же паттерн вы реализуете, или речь про сферических конях?

Возьмем для примера абстрактную фабрику.
Например:

class AbstractFactory {
public:
    virtual A *CreateA() = 0;
    virtual B *CreateB() = 0;
    ...
};

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

AVC>>В динамических языках какой-нибудь оператор x = "Hello!" ничуть не лучше скрывает тип, чем в Си++ p = new String("Hello!").
AVC>>В динамическом языке, чтобы сохранить гибкость при порождении объекта, тебе точно также придется прибегнуть к паттерну.

FR>Который выродится просто в строку кода на этом динамическом языке.

Например?

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

AVC>Возьмем для примера абстрактную фабрику.
AVC>Например:
AVC>

AVC>class AbstractFactory {
AVC>public:
AVC>    virtual A *CreateA() = 0;
AVC>    virtual B *CreateB() = 0;
AVC>    ...
AVC>};
AVC>

Постановка задачи очень неполна, непонятно откуда у нас берётся фабрика — на базе чего? Если так то можно одной строчкой обойтись типа

A = SuperPuperA.new