Применимы ли паттерны GoF для LISP?

А ты правда понял то, что сказал?

нет, конечно

долго ли надо курить Хаскелль, чтобы это понять?

можно вообще не курить. приходи в гости, на доске нарисую

Полегчало? ;)

да

> долго ли надо курить Хаскелль, чтобы это понять? я из этого ничего не понял... http://www.haskell.org/haskellwiki/Zygohistomorphic_prepromorphisms

думаю курить надо не только Хаскелл

i take thee at thy word!
call me but love and ^U

> .. http://www.haskell.org/haskellwiki/Zygohistomorphic_prepromorphisms

Особенно нравится комментарий:

 — unless you want a generalized zygomorphism.

ага да, это меня вообще высадило

> Ошибка. Не важно, есть у нас в языке синтаксические средства для создания цикла или нет - цилк всё равно остаётся циклом и мы будем называть его циклом.

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

И это именно та информация, которую я хотел сообщить коллеге.

Как я уже сказал - проблема в том, что паттерн не определяется своей функцией. Вы передаете лишнюю информацию, которая может оказаться и неверна. Вы, конечно, можете понимать под «паттерном» не то, что понимают в классическом варианте - но это уже ваше личное дело.

Паттерн именно что определяется своей функцией в отношении конкретного кода.

Конечно, нет.

Мы можем отдельно рассмотреть то, что код является циклом, и отдельно - условие и тело конкретного цикла.

Ну вот вы и сами признали, что только функции недостаточно. Вот смотрите: for(int i = 0; i < 2; i++) j++; - это цикл (считаем его развернутым для goto и if), а теперь: i=0, j+=i, i=1, j+=i - это тоже паттерн, этот паттерн в данном случае выполняет ту же самую функцию, что и предыдущий цикл, это один и тот же паттерн? Нет, это разные паттерны, потому что в них применяются разные конструкции.

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

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

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

Так в том и дело - язык будет покрывать все понятие функции, а не какую-то функцию по-отдельности. В этом преимущество по сравнению с паттернами, кстати - языковое средство универсально. Его реализовал один раз - и все. Каждую же реализацию паттерна мы всегда пишем руками - потому что мы _не можем_ устойчиво выразить общее решение в рамках языка. Например - у нас есть условия, goto и макросы. Мы пишем макрос for - и это универсальное решение. Теперь мы просто используем for. В случае с паттернами мы так и будет каждый раз писать лапшу из goto. И в этом случае говорить о паттернах, конечно, удобно. Но если у нас и так лапши из goto нет - нам и паттерны не нужны,макрос уже решил задачу, которую бы здесь решили паттерны.

> Паттерн - это ОБРАЗЕЦ решения какой-либо проблемы.

Угу, вопрос в том - какие именно проблемы. Если брать гофовские паттерны - это проблемы построения иерархии классов, которые в не-ООП языках просто не имеют смысла. Там другие проблемы (абсолютно другие) и другие (совершенно другие) методы их решения. И другие паттерны, соответственно. Собственно, все формулировки ф-й паттернов из гофа вне ООП даже не имеют какого-то смысла. Их придется переформулировать и притягивать за уши, после чего у них смысл поменяется на противоположный. И тут вывод простой - если есть фвп/макросы, то паттерны резко становятся ненужными. Потому что любое подобное «решение» какой-либо «проблемы» нам нахрен не нужно описывать, чтобы кто-то его заново велосипедил - можно просто написать соответствующую ф-ю/макрос, которую и можно будет просто брать и использовать. Без пустопорожних рассуждений о «паттернах».

> И тут вывод простой - если есть фвп/макросы, то паттерны резко

становятся ненужными.

Один из самых известных сейчас паттернов - это ActiveRecord (правда не от GoF, а от Фаулера). Каким образом фвп/макросы делают его ненужным? У GoF просто примитив, а техники на базе той же ActiveRectord или там Reactor/Proactor это уже как бы посложнее, особенно с учётом того, что данные паттерны есть обширная практическая база с анализом использовавшихся решений.

«резко» было не в том смысле, что «совсем». какие-то паттерны, конечно, все равно будут нужны.

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

Если тот, к кому обращаемся, не знает, что такое цикл - то придётся. Но лучше не иметь дела с таким дубом.

Мы можем отдельно рассмотреть то, что код является циклом, и отдельно - условие и тело конкретного цикла.

Ну вот вы и сами признали, что только функции недостаточно.

Где? Ты отчаянно тупишь, и по никому не ведомой причине хочешь, чтобы паттерн описывал _всё_. А это не его работа. Паттерн описывает код только в одной плоскости - связанности разных частей кода. Описывать, что же именно делает код в предметной области - это уже не работа паттерна.

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

Конечно, нет. Паттерн - это довольно-таки низкоуровневая абстракция. Просто потому, что паттерны пришли из ООП языков

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

язык будет покрывать все понятие

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

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

Нет, не потому, что не можем (в плюсах можно легко забабахать на шаблонах те же самые фабрику и синглтон), а потому что не нужно. Нам не нужна сферичесая _реализация_ паттерна в вакууме. Потому что паттерн - это не шаблон и не сниппет. Можно ли все циклы свести к единому for_each?

Мы пишем макрос for - и это универсальное решение. ... Но если у нас и так лапши из goto нет - нам и паттерны не нужны,макрос уже решил задачу, которую бы здесь решили паттерны.

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

Пойми, наконец, что любые, повторяю - _любые_ - синтаксические средства языка в самом лучшем случае могут вытянуть только на частный случай реализации паттерна.

> Нам не требуется привлекать лишние средства выражения (паттерна), мы можем все выразить в рамках понятий ЯП.

Вы так говорите, как будто можете выразить все 23 паттерна GoF и 23 паттерна J2EE в рамках понятий Common Lisp. Может, приведёте примеры?

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

Вот и вы тоже так говорите, как будто можете выразить все 23 паттерна GoF и 23 паттерна J2EE в рамках понятий Common Lisp. Может, вы тоже приведёте примеры?

> Потому что любое подобное «решение» какой-либо «проблемы» нам нахрен не нужно описывать, чтобы кто-то его заново велосипедил - можно просто написать соответствующую ф-ю/макрос, которую и можно будет просто брать и использовать. Без пустопорожних рассуждений о «паттернах».

Так может, приведёте примеры решения при помощи ФВП/макросов проблем, которые решают 23 паттерна GoF и 23 паттерна J2EE?

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

Т.е. типа я много потеряю от этого? Посмотрел ваши сообщения, вы не интересуетесь проблематикой языков программирования, поэтому максимум, что вы можете привести - это мнение большинства. А его я уже знаю, так что я не теряю ничего.

Судя по твоим комментариям, ты недалёкий, хамоватый тролль.

Человека, который ещё ни разу никого не назвал на «ты», обхамили, назвали троллем, хамом и на «ты» :) Но я не обижаюсь, ЛОР же

> Вывод примерно такой: шаблоны — это костыли, которые нужны в ограниченных языках. В языках вроде Lisp такой необходимости в них нет.

Вы вообще книжку читали? Я вот прочитал. Спасибо кстати за ссылку. Он там не только рассматривает реализацию известных паттернов в Common Lisp, но и вводит новые.

Собственно, теперь у меня сформировалось окончательное мнение на счёт вопроса, всем спасибо

Зачем ты спрашиваешь свои ответы тут, если тебя не интересует мнение большинства, бро?

> Зачем ты спрашиваешь свои ответы тут, если тебя не интересует мнение большинства, бро?

Вы невнимательно читали, с мнением большинства я уже ознакомился. Поэтому ещё раз проговорённое (вами), оно меня не интересует.
Насчёт «мнения большинства» и его ценности конечно много можно рассуждать, но сейчас не об этом.

> Паттерн описывает код только в одной плоскости - связанности разных частей кода.

Вот именно. Частей кода. А в разных языках - разные части кода. Вот в ООП части кода - это, например, интерфейсы и классы. И если паттерн описывает связи между интерфейсами и классами - то он неприменим в ЯП, где нету интерфейсов и классов.

Паттерны реализуются на множестве языков и уже по этому являются внеязыковой абстракцией. Всегда ваш, Кэп.

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

Покрывать всё - это тоже самое, что ничего.

Это ты к чему сказал? Я разве где-то говорил про покрытие всего?

Нет, не потому, что не можем

Именно потому что не можем.

Нам не нужна сферичесая _реализация_ паттерна в вакууме. Потому что паттерн - это не шаблон и не сниппет

Вот по-этому и не можем. Нужна поддержка со стороны языка - а ее нет.

Можно ли все циклы свести к единому for_each?

Конечно, нет. Но ведь просто «цикл» - это и не паттерн. Паттерном будет лишь какой-то конкретный вид циклов. Например do-while - паттерн, for-each - паттерн и так далее. И все это - разные паттерны, которые имеют разные, ортогональные функции, реализации и так далее. то есть - ничего общего.

Да ничего макрос ни решил, кроме того, что инстанцировал одну конкретную реализацию паттерна,

Нет, в том и дело - не одну конкретную, а ВСЕ. Конкретную реализацию паттерна мы получаем, подставляя в макрос конкретное условие и тело.

Все остальные варианты реализации паттерна (а их бесконечное количество, хе-хе) остаются за кадром.

Нет. Любая реализация паттерна получается из этого макроса при подстановке нужных аргументов.

Пойми, наконец, что любые, повторяю - _любые_ - синтаксические средства языка в самом лучшем случае могут вытянуть только на частный случай реализации паттерна.

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

> Вы так говорите, как будто можете выразить все 23 паттерна GoF и 23 паттерна J2EE в рамках понятий Common Lisp.

С какого начать?

Вот и вы тоже так говорите, как будто можете выразить все 23 паттерна GoF и 23 паттерна J2EE в рамках понятий Common Lisp.

Хм. А где я это говорю? Я вообще не знаю common lisp. Да и это как-то не вяжется с моим утверждением. Я думаю часть паттернов для common lisp подходит (тот же dao, почему бы и нет), часть не подходит и есть еще свои специфичные паттерны, которые применимы только для common lisp.

> У A есть connection point «foo». У B есть connection point «bar» с одинаковой сигнатурой. Эти две сущности связываются в рантайме при помощи чего-то типа рефлексии. Если сигнатура bar или foo изменилась, ошибка всплывет во время инициализации программы

ну это еще можно назвать типизацией:

здесь мы утверждаем: если программа вообще запустилась (а еще лучше — если запускаемость программы проверил разработчик), то ситуация «модуль А не сможет вызвать модуль В» невозможна

или даже позже если инициализация ленивая.

а это вообще не типизация, даже не динамическая

Система типов — это гибко управляемый

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

это определение из tapl

ну так какое поведение в твоем случае доказанно отсутствует?

Речь какбе о том что синглтон это нормальная статическая зависимость между двумя модулями. Оппоненты при этом утверждают что синглтонов быть не должно. Я эту позицию оппонентов понял как «статических зависимостей между модулями быть не должно». Оппоненты с этим не согласились.

в отпуск тебе надо, Архитектор.

насчет синглтона согласен — функция с состоянием ничем не лучше

а вот насчет типизации не согласе

>> Паттерн описывает код только в одной плоскости - связанности разных частей кода.

Вот именно. Частей кода. А в разных языках - разные части кода.

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

Вот в ООП части кода - это, например, интерфейсы и классы. И если паттерн описывает связи между интерфейсами и классами - то он неприменим в ЯП, где нету интерфейсов и классов.

Ничего подобного. Можно без проблем забубенифть фабрику на голом ассемблере.

Но ведь просто «цикл» - это и не паттерн.

Это именно что паттерн.

Паттерном будет лишь какой-то конкретный вид циклов.

С чего ты это взял? Конкретный вид цикла будет _реализацией_ паттерна «цикл».

Вот по-этому и не можем. Нужна поддержка со стороны языка - а ее нет.

Да не нужна никакая поддержка.

Да ничего макрос ни решил, кроме того, что инстанцировал одну конкретную реализацию паттерна,

Нет, в том и дело - не одну конкретную, а ВСЕ.

Любая реализация паттерна получается из этого макроса при подстановке нужных аргументов.

Окей, вот тебе конкретная задача: имеем API из пяти функций f1-f5 и две структуры данных d1-d2. f1 возвращает валидную d1, f2 возвращает валидную d2 и использует в качестве аргумента d1 , f3, f4 используют d2 в качестве аргумента, f5 принимает аргументом d1, после вызова f5 d1 и любые полученные по ней d2 более не валидны, мы обязаны вызвать f5 по окончании работы.

Нам нужны только f3-f4, которые мы хотим видеть как F1-F2. Реализуй для них паттерн Bridge. Для простоты порядок вызовов определен как строго последовательный - сначала F1, потом F2.

>> Вы так говорите, как будто можете выразить все 23 паттерна GoF и 23 паттерна J2EE в рамках понятий Common Lisp.

С какого начать?

Вот с Brigde и начни.

> Вовсе нет. Один и тот же алгоритм, одни и те же структуры данных можно выразить на самых разных языках программирования.

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

Ничего подобного. Можно без проблем забубенифть фабрику на голом ассемблере.

Если вы перед этим забубените классы с интерфейсами (что тоже можно) то конечно. Но при чем тут это?

Это именно что паттерн.

Нет, паттерном будет какой-то конкретный вид итерации.

С чего ты это взял? Конкретный вид цикла будет _реализацией_ паттерна «цикл».

Конкретным видом цикла будет конкретный цикл, например for(init; test; incr) body; - паттерн, for(int i = 0; i < 10; i++) j+=i; - реализация.

Да не нужна никакая поддержка.

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

Реализуй для них паттерн Bridge.

Нет, так не пойдет. Вы скажите какую задачу надо решить, зачем изображать паттерн, когда это ненужно?

> Вот с Brigde и начни.

В рамках CL - не нужен (так же, например, как в scheme не нужен паттерн «цикл», потому что там применим другой паттерн - «рекурсия»). Следующий паттерн?

> Паттерн привязан к этим конструкциям намертво.

Это твои фантазии, которые к реальным паттернам не имеют никакого отношения. Ты просто не понимаешь, что такое «паттерн», по причине нулевого опыта в разработке ПО.

если в паттерне участвуют, например, классы - мы не можем взять и заменить их на функции.

Почему не можем? Можем. Вообще без проблем.

Да не нужна никакая поддержка.

Если бы не была нужна - все паттерны уже бы давно реализовали. но их не реализовали.

То есть как «не реализовали»? Что, совсем-совсем нигде в природе нет фабричного метода ?!? xDDD

Реализуй для них паттерн Bridge.

Нет, так не пойдет. Вы скажите какую задачу надо решить,

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

зачем изображать паттерн, когда это ненужно?

А кто тебе сказал, что не нужно? Если бы это было не нужно, паттернов бы не было.

>> Вот с Brigde и начни.

В рамках CL - не нужен

Докажи. Код в студию.

Следующий паттерн?

Какой тебе «следующий», если ты даже этого не знаешь? Пустой болтовнёй тебе не отделаться.

>>> Вот с Brigde и начни.

В рамках CL - не нужен

Докажи.

В CL он бессмыслен чуть более, чем полностью, ибо проблемы, для решения которых предназначен Bridge, рулятся за счёт мультиметодов, динамических переменных и т.д. Т.е. городить Bridge в коде на CL в явном виде никто в здравом уме не будет.

Вообще идея разделения абстракции и реализации для CL бессмысленна, ибо методы не принадлежат какой-либо сущности (абстракции).

> проблемы, для решения которых предназначен Bridge, рулятся

городить Bridge в коде

Взаимоисключащюие параграфы. Либо проблемы руляться, либо не городить.

> Взаимоисключащюие параграфы

Хм, почему?

> Это твои фантазии, которые к реальным паттернам не имеют никакого отношения.

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

Почему не можем? Можем. Вообще без проблем.

Можем, правда? Ну давай - допустим, у нас есть класс Number для работы с числами, на какую функцию ты его собрался менять?

То есть как «не реализовали»? Что, совсем-совсем нигде в природе нет фабричного метода ?!? xDDD

Конечно, нету. Более того - на языках типа той же джавы и реализовать его в принципе невозможно - потому что, как я сказал, выразительных средств не хватает. Можно реализовать только конкретный инстанс паттерна, но не сам паттерн.

А ты иди и посмотри, какую задачу решает паттерн Bridge

Для решения твой задачи не нужен паттерн bridge, заадача стояла следующая:

Нам нужны только f3-f4, которые мы хотим видеть как F1-F2

имеем реализацию:

(define-values (F1 F2) (values f3 f4))

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

А кто тебе сказал, что не нужно?

Я сказал, что в описанной вами задаче - это не нужно. Зачем лепть паттерны для задачи, которая решается в одну строчку?

Если бы это было не нужно, паттернов бы не было.

Ну так паттерны языка А нужны для языка А. Но, вполне возможно, не нужны для языка В. Вот в А их и используют. А в В - нет. Топикстартер и спрашивал - почему? А потмоу что - не нужно.

> Докажи. Код в студию.

Будет задача - будет код. Нет задачи - нет кода. Все очевидно же. Вообще, раз вы задачу для демонстрации паттерна bridge поставить не в состоянии (или не знаете, зачем этот паттерн нужен или просто в силу своего косноязычия - не знаю уж) - я ее поставлю сам. Есть некоторый набор групп функций А и выделенный набор ф-й В. Цель - параметризовать ф-и В конкретными наборами А. Если отвлечься от классов - то сразу видно, что никаких паттернов для такой задачи не нужно совершенно, мы можем просто передавать нужную группу ф-й напрямую и делать замыкания. Если говорить о классах - то в решении на CLOS тоже не будет никакого паттерна bridge - потому что корни иерархий сольются в один класс, а иерархия абстракции выльется в набор CLOS-овский ф-й, то есть мы останемся с одной иерархией (которая, вообще говоря, дана в задаче, ее мы не реализуем), поверх которой реализован ряд ф-й. Ничего общего с bridge это, конечно же, не имеет - мы просто вместо явной параметризации группами ввели тоненькую прослойку-интерфейс, которая будет диспатчить ф-и по группам средствами CLOS.

Стесняюсь спросить, у тебя тоже код растёт сам по себе, без участия программиста? ;)

> допустим, у нас есть класс Number для работы с числами, на какую функцию ты его собрался менять?

На любые, которые реализуют его функциональность. Всегда ваш, К.О.

То есть как «не реализовали»? Что, совсем-совсем нигде в природе нет фабричного метода ?!? xDDD

Конечно, нету.

xDDD

Иди по этой ссылочке

http://download.oracle.com/javaee/6/api/

и подсчитай количество упоминаний слова Factory. Потом возвращайся и повтори свои слова. ;)

А ты иди и посмотри, какую задачу решает паттерн Bridge

Для решения твой задачи не нужен паттерн bridge, заадача стояла следующая:

Нам нужны только f3-f4, которые мы хотим видеть как F1-F2

имеем реализацию:

(define-values (F1 F2) (values f3 f4))

никаких паттернов вообще не надо

Ты дурачок? Мне не нужно в коде приложения видеть f1,f2,f5. Мне нужны только f3 и f4. Сам сообразишь, что будет с твоим кодом, если просто вызывать F1?

и в принципе не ясно в чем сложность.

А сложности в принципе и нет - задачка для школьника-восьмиклассника. Правда ты с ней почему-то не справился..

может, имелась ввиду какая-то другая задача?

Да ты сначала эту реши, горе-программист.

Ну так паттерны языка А нужны для языка А.

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

> Стесняюсь спросить, у тебя тоже код растёт сам по себе,

без участия программиста? ;)

А зачем вы это спрашиваете?

> Есть некоторый набор групп функций А и выделенный набор ф-й В. Цель - параметризовать ф-и В конкретными наборами А.

Ничего общего с bridge это, конечно же, не имеет

Правильно. Задачу, которую ты сам себе нарисовал, ничего общего с паттерном Bridge не имеет. Иди решай ту задачу, что дал я. Я её дополню, тогда ты поймешь, что такое паттерн Bridge, если уж из википедии вычитать не осилил.

Что бы навести тебя на мысль об ответе на твой же вопрос:

Хм, почему?

> Что бы навести тебя на мысль об ответе на твой же вопрос:

Хм ,вы тут исключительно только для того, что бы потроллить?

> Хм ,вы тут исключительно только для того, что бы потроллить?

Он тролль, но он прав в главном - паттерны являются внеязыковыми (или над-языковыми) конструкциями. Они описывают то, что готовыми конструкциями языка не выразимо. Возможно, в CL паттерны GoF не нужны, но тогда в CL есть какие-то свои паттерны.

P.S. первую книгу о pattern languages написал архитектор. Об архитектуре.

> На любые, которые реализуют его функциональность. Всегда ваш, К.О.

Стоп-стоп, какие любые? Мы говорили про _функцию_, а не _функции_.

Иди по этой ссылочке

Прошел. реализации паттерна Factory, как и ожидал, нету - только его инстансов. Будут еще попытки?

Мне не нужно в коде приложения видеть f1,f2,f5.

Ну так не экспортируй эти f1,f2,f5 из своего модуля, экспортируй только F1, F2.

Сам сообразишь, что будет с твоим кодом, если просто вызывать F1?

В условиях твоей задачи ее нельзя вызвать. Т.к. F1 должна принять d2, а d2 можно получить только из f2. Но f2 у нас нет, а значит и d2 мы получить не можем. То есть ни F1 ни F2 просто не к чему применять, мы не сможем передать нужный аргумент.

А сложности в принципе и нет

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

Да ты сначала эту реши

Так я решил. реализацию привел. Что тебе еще надо? Что, решение не соответствует постановке? Укажи в каком пункте.

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

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

> паттерны являются внеязыковыми

Возможно, в CL паттерны GoF не нужны, но тогда в CL есть какие-то свои паттерны.

Что-то тут не то. Если паттерн - конструкция внеязыковая, то не может быть у языка «своих паттернов».

Они описывают то, что готовыми конструкциями языка не выразимо.

Именно так. Но в разных языках есть разные конструкции... дальше продолжать или сам догадаешься?

> Если паттерн - конструкция внеязыковая, то не может быть у языка «своих паттернов».

Подсказать или сам догадаешься?

в разных языках есть разные конструкции... дальше продолжать

Даже начинать не нужно было.

> Подсказать или сам догадаешься?

или кино - или мороженое. или во всех языках паттерны одинаковые (вообще понятия «паттерн для языка» некорректно), или они не являются внеязыковыми

Даже начинать не нужно было.

Интересно, что первично - страсть к паттернам или врожденная тупость?

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