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

VD>Ну, и? Уж сколько не сравнивали, а все одно приходим к выводу, что 99% использования С++ есть результат фобий и фанатичной привязанности к нему.

А 99% обвинений в адрес C++ следствие патологического неумения им пользоваться.

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

S>>Свойство — это, вообще говоря, паттерн.
VD>Ты не верно интерпретируешь понятие "паттерн".

Синклер как раз паттерн и описал.

VD>По-моему, паттерн — это некий стандартный способ эмуляции некоего подразумеваемого поведения или свойства.

Паттерн — просто общая схема.

VD>Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка.

Ну, поехали противопоставлять не противопоставимое.

VD>А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.

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

VD>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

В C++ нету паттернов, потому что паттерны не являются частью спецификации C++. Смекаешь?

VD>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.

Хм. Сам-то понял, что сказал? Как это можно встроить "паттерн", который не является частью спецификации языка? Чё-то тут не так в консерватории.

VD>Вопрос только в качестве и простоте этого изменения.

Прежде чем говорить о "качестве" неплохо определиться с показателями этого самого "качества".

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

ГВ>А 99% обвинений в адрес C++ следствие патологического неумения им пользоваться.

Ты уже доказал, что я там, IT или Вольфхаунд паталогически неумеем им пользоваться? Раз нет, то будем придерживаться мнения, что пользоваться им неумешь ты или еще кто. ОК?

К тому же тут не обвиняется сам С++. Глупо обвинять продукт. Обвиняются те дуболомы которые пишут на нем прикладной софт и тот дуболом который его спроектировал.

Сам же С++ нормальный продукт рекламы. Массам влили в уши что писать нужно на нем они и повелись. Сейчас слава богу вливают более разуный выбор. Будем надеяться, что результат повторится.

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

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

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

VD>>Ты серьезно считашь паттерн-матнчинг реализацией Посетителя? Я вот так не считаю. Однако нужда в Посетителе при этом отпадает. Причем код при этом получается более высокоуровневым. А ведь паттерн-матчинг не более чем сахар. Все что он делает можно сэмулировать паттернами проектирования на if-ах.

FR>Нет. Патерн-матчинг не может полностью заменить посетителя (вот мультиметоды могут) с его помощью просто удобно решать многие из тех задач для решения которых был придуман посетитель.

Акстись. Посетитель идет лесом при наличии паттерн матчинга. Этот ублюдочный паттерн нужен исключительно потому, что в современных ООЯ нет полноценных и выразительных средств распознования полиморфных объектов.

Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.

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

VD>>Это только по-твоему.

IT>По-моему тоже.

Ну, и зря.

VD>>Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.

IT>Под оными ты понимаешь паттерны, правильно?

Вот определения паттерна проектирования:
http://en.wikipedia.org/wiki/Special:Search?search=pattern+GOF

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0201633612) is a software engineering book proposing standard solutions and naming conventions to common problems in software design.

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

Другой пример — итераторы. Когда в Яве (до 1.5) я вынужден прибегать к "стандартным решениям и солашениям по именованию" для того чтобы и реализовать нужное мне поведение и использовать его, то я имею дело с чистым паттерном проектирования. В коде я виже не этот паттерн, а код его реализующий. При этом я вынужден мысленно декодировать паттерн в код, и наоборот воссоздовать по коду паттерн (хотя бы уметь разглядеть паттерн в коде).
В C# 1.х мне уже проще. Я могу переложить отвественность за перебор последовательностей на компилятор. Причем он сам разберется использовать ли паттерн проектирования Итератор (т.е.е IEnulerable/IEnumerator) или просто переписать код в паттерн кодирования:

for (int i = 0; i < array.Length; i++)
{
    SomeType elem = array[i];
    ...
}

и так далее.
Однако я по прежнему обязан использовать паттерн проектирования Итератон чтобы реализовать возможность перебора значений своей коллекции. Задача конечно может быть облегчена наличием базовых классов, но в общем случаея я вынужден опять же кодировать паттерн и распозновать его в коде.
В C# 2.0 я получаю ко всему прочему возможность под названием Итератор:

IEnulerable Xxx(...)
{
    ...
  yield ...
}

Это паттерн? Мне не нужно что либо декодировать или распозновать в коде. Я имею дело с конструкцией языка. Да его идея основан на паттерне, но для меня это уже не паттерн — это уже часть языка. Итераторы C# 2.0 позволяют мне оперировать более высокоуровневыми сущьностями нежели "стандартным решениям и солашениям по именованию". Они вводят синтаксис в язык и берут на себя заботу о реализации.

Вот что отличает возможность языка от паттерна проектирования.

Мне не нужно уже оперировать понятием паттернв в языке где есть нужные возможности.

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

ГВ>Паттерн — просто общая схема.

Именно. И если схемы нет, а есть конкретный синтаксис, то о паттерне уже говорить глупо. Иначе можно говорить о паттерне statment, expression, if, while, for и т.п.

VD>>Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка.

ГВ>Ну, поехали противопоставлять не противопоставимое.

Тебе показалось.

VD>>А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.

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

А вот если не разводить софистику по каждому поводу, то можно сойтись, что на этом форуме мы под словом "паттерн" понимаем "паттерн проектирования" по GoF. И ни как не из области психологии или судебной медицины. Так что это направление мыслительной деятельности мы закроем ен открыв.

VD>>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

ГВ>В C++ нету паттернов, потому что паттерны не являются частью спецификации C++. Смекаешь?

В С++ нет: свойств, интерфейсов, указателей на функции объектов и т.п. И когда кто-то говорит о данных сущьностях в языке, то имеет в виду как раз паттерн. А говорят о них много и часто. Многие свято уверены, что в С++ есть те же интерфейсы, как не странно. А многие считают boost::lambda частью С++, хотя это тоже только лишь паттерн реализованный во внешней библиотеке.

VD>>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.

ГВ>Хм. Сам-то понял, что сказал?

Да. Но ты не расстраивайся. Без некоторой подготовки это можно легко не понять.

ГВ> Как это можно встроить "паттерн", который не является частью спецификации языка? Чё-то тут не так в консерватории.

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

VD>>Вопрос только в качестве и простоте этого изменения.

ГВ>Прежде чем говорить о "качестве" неплохо определиться с показателями этого самого "качества".

А они очевидны:
1. Бесшовность интеграции с другими возможностями языка.
2. Неотличимость встаеваемого паттерна от встроенных возможностей языка.
3. Отсуствие значительного снижения скорости компиляции.
4. Качественные сообещения об ошибках и дагностичесие сообщения.
5. Гибкость решений которые можно получить таким образом.

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

ГВ>>Паттерн — просто общая схема.
VD>Именно. И если схемы нет, а есть конкретный синтаксис, то о паттерне уже говорить глупо. Иначе можно говорить о паттерне statment, expression, if, while, for и т.п.

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

VD>>>Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.
ГВ>>В C++ нету паттернов, потому что паттерны не являются частью спецификации C++. Смекаешь?
VD>В С++ нет: свойств, интерфейсов, указателей на функции объектов и т.п. И когда кто-то говорит о данных сущьностях в языке, то имеет в виду как раз паттерн. А говорят о них много и часто.

Почти всё почти так, за исключением указателей на функции объектов, кои в C++ есть.

VD>Многие свято уверены, что в С++ есть те же интерфейсы, как не странно. А многие считают boost::lambda частью С++, хотя это тоже только лишь паттерн реализованный во внешней библиотеке.

Верно. Именно реализованный во внешней библиотеке.

VD>>>И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу.
ГВ>>Хм. Сам-то понял, что сказал?
VD>Да. Но ты не расстраивайся. Без некоторой подготовки это можно легко не понять.

Паттерны можно реализовать на ассемблере. Ergo, ассемблер — высокоуровневый и выразительный язык.

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

Не "встроить паттерн", а "реализовать паттерн". В этом и заключено передёргивание и объект моих насмешек: паттерн в общем случае не связан с целевым языком. Соответственно, когда ты рассуждаешь о "встраивании паттернов" на самом деле речь должна идти об их реализации. И если перевести твои и им подобные рассуждения с маркетологического на нормальный, то получится, что мы говорим не о волшебной магической колдовской палочке, способной впихнуть невпихуемое ("встроить паттерн"), а о вполне банальной вещи: реализации паттернов средствами языка програмирования. И коль скоро мы говорим о реализации, которая всегда сугубо конкретна, то мы неизбежно должны учитывать, что данная конкретная реализация всего лишь одна из многих возможных, со своими преимуществами и недостатками, и далее в том же духе.

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

ГВ>> Как это можно встроить "паттерн", который не является частью спецификации языка? Чё-то тут не так в консерватории.
VD>Вот так. Если язык позволяет расширение синтаксиса и семантики, то с разным успехом можно встроить паттерн в язык.

Это означает, что базовым языком является не тот, который изменяется, а тот, на чём эти изменения написаны, только и всего. Полученное подмножество суть domain-specific language, хоть ты тресни.

VD>>>Вопрос только в качестве и простоте этого изменения.
ГВ>>Прежде чем говорить о "качестве" неплохо определиться с показателями этого самого "качества".
VD>А они очевидны:

А вот это уже интересно.

VD>1. Бесшовность интеграции с другими возможностями языка.

Что есть "шов" в данном случае? Если взять аналогичный термин из лексикона интеграторов, то они так обозначают необходимость писать некий софт для связи программ между собой. Очевидно, что, например, при использовании boost::function подобного шва и в помине нет.

VD>2. Неотличимость встаеваемого паттерна от встроенных возможностей языка.

В чём заключена "отличимость" в таком случае?

VD>3. Отсуствие значительного снижения скорости компиляции.

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

VD>4. Качественные сообещения об ошибках и дагностичесие сообщения.

Ну давай, раскрывай тему о качественных сообщениях.

VD>5. Гибкость решений которые можно получить таким образом.

Здесь поконкретнее, плз. Например, функторы STL можно передать по ссылке, создать, удалить и т.п. Никаких ограничений.

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

ГВ>>А 99% обвинений в адрес C++ следствие патологического неумения им пользоваться.
VD>Ты уже доказал, что я там, IT или Вольфхаунд паталогически неумеем им пользоваться?

Ты апеллируешь к "фобиям" и "фанатизму", я — к "патологическому неумению". Это просто симметричная формулировка. На самом деле и то и другое обвинение — глупости.

VD>Раз нет, то будем придерживаться мнения, что пользоваться им неумешь ты или еще кто. ОК?

Можно поиграться, но и ты тогда докажи, что у твоих оппонентов именно "фобии" и "фанатическая привязанность". А мы до тех пор будем считать истинным утверждение, что фобии и фанатическая ненависть (или паче чаяния — привязанность?) — у тебя. И от такого славного персонажа, богатого фобиями и ненавистью я вполне принимаю обвинения в том, что не умею пользоваться C++.

А ещё есть конструктивный вариант: откажемся от таких утверждений на паритетной основе. Но тебе придётся отказаться первому.

VD>К тому же тут не обвиняется сам С++. Глупо обвинять продукт. Обвиняются те дуболомы которые пишут на нем прикладной софт и тот дуболом который его спроектировал.

Что там у нас по поводу поворачивания субъектных утверждений на 180 градусов?

VD>Сам же С++ нормальный продукт рекламы. Массам влили в уши что писать нужно на нем они и повелись. Сейчас слава богу вливают более разуный выбор. Будем надеяться, что результат повторится.

Знаешь, иногда меня просто шокируют такие рассуждения. На самом деле, продуктом рекламы является психоз вокруг .Net/Java и никто из этого не делает ни тайны, ни открытия. Но назвать С++ продуктом рекламы — это ты сильно загнул!

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

VD>>>Это только по-твоему.
IT>>По-моему тоже.
VD>Ну, и зря.

Это не то, чтобы "и зря", это не только не зря, это просто — правильно.

IT>>Под оными ты понимаешь паттерны, правильно?

VD>Вот определения паттерна проектирования:
VD>http://en.wikipedia.org/wiki/Special:Search?search=pattern+GOF
VD>

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0201633612) is a software engineering book proposing standard solutions and naming conventions to common problems in software design.

Это не определение паттерна проектирования. Это краткое описание книжки, в которой описан набор наиболее общих паттернов проектирования.

Вот правильная ссылка Design pattern (computer science)

In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design.

VD>Так вот если в языке есть средства позволяющие не прибегать к "стандартным решениям и солашениям по именованию", то глупо называть их паттернами.

От того что некоторые паттерны непосредтственно реализуются языковыми конструкциями они не перестают быть паттернами. Те 26 (или сколько их там) паттернов из книжки GOF — это не все возможные паттерны, это лишь их небольшое множество. Как раз одна из моих наиважнейших задач как архитектора выделить и определить паттерны в дизайне моего приложения. И то, что это будут паттерны в дизайне только этого приложения и они не будут входить в число 26-ти гофовских, совсем не означает, что это не паттерны.

VD> Например, паттерн-матчинг имеет мало общего с паттерном проектирования Посетитель. Однако при наличии первого второй теряет смысл. В принципе теряет.

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

VD>Так как то что получается с помощью "стандартного решения и солашений по именованию" нманого менее удобно и более трудоемко чем стандартная возможность языка которая ко всему прочему являюется куда более универсальным решением.

С этим никто не спорит. Спорят тут с тем, что ты неверно для себя сформулировал понятие паттерн проектирования и совершенно необоснованно ограничил его примерами из книжки GOF.

VD>Вот что отличает возможность языка от паттерна проектирования.

Эти вещи нельзя сравнивать. От реализации паттерна средствами языка, паттерн не исчезает. Он просто реализуется средствами языка.

VD>Мне не нужно уже оперировать понятием паттернв в языке где есть нужные возможности.

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

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

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

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

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

VD>Понимаш ли, если я могу выразить мысль кратко и доступно, применив при этом возможности языка описанные во введение в этот язык, то "типовых решений" мне не нужно. Типовые решения нужны там где язык не предоставляет удобного и простого способа решения проблемы. Посетитель как раз тот случай. Паттерн в принципе не нужен в более мощьных языках. Именно по этом все функциональщики в один голос говорят, что созадние парсеров и компиляторов на ФЯ получается лучше всего.

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


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

Интересно

VD>Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.

Покажи мне там же хоть один объект.

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

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

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

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

ГВ> А мы до тех пор будем считать истинным утверждение, что фобии и фанатическая ненависть (или паче чаяния — привязанность?) — у тебя. И от такого славного персонажа, богатого фобиями и ненавистью я вполне принимаю обвинения в том, что не умею пользоваться C++.

Ну, это понты и пустословье. Оставим это.

ЗЫ

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

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

VD>>Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.

FR>Покажи мне там же хоть один объект.

http://nemerle.org/svn/nemerle/trunk/ncc/passes.n

Твой ход.

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

VD>>>>Это только по-твоему.
IT>>>По-моему тоже.
VD>>Ну, и зря.
IT>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.

В столь конструктивной беседе могу только продолжить ряд — не правильно.

IT>Это не определение паттерна проектирования. Это краткое описание книжки, в которой описан набор наиболее общих паттернов проектирования.

IT>Вот правильная ссылка Design pattern (computer science)

IT>

In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design.

Что в лоб, что полбу. Смысл не изменяется.

IT>От того что некоторые паттерны непосредтственно реализуются языковыми конструкциями они не перестают быть паттернами.

Перестают. Они перестают быть "repeatable solution". Они превращаются в синтаксис языка. К тому же речь не идет о тупом переносе паттернов в язык. Речь идет о создании более высокоуровневых решений.


IT> Те 26 (или сколько их там) паттернов из книжки GOF — это не все возможные паттерны, это лишь их небольшое множество.

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

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

Всякая иделогия вгоняет в свои рамки. Ты слишком погрузился в рамки паттернов. Оторвись от нее и просто скажи будешь ли ты мыслить паттернами описывая арефмитическое выражение, например?

Вот и я говорю о том, что в зависимости от языка ты будешь выделять разный набор паттернов. Те что нужны в одном языке окажуется совсем бессмысленными в другом. В ассемблере для тебя даже if — это паттерн. А в каком нибудь Немерле тебе не нужны даже Посетители.

VD>> Например, паттерн-матчинг имеет мало общего с паттерном проектирования Посетитель. Однако при наличии первого второй теряет смысл. В принципе теряет.

IT>Смысл теряет только необходимость реализации этого паттерна в ручную в языках, имеющих более мощные встроенные средства.

Смысл теряет вообще думать о паттерне. Все становится очевидно. Мы просто пишем код:

match (comeObj)
{
    A => действия для A
    B => действия для B
    C => действия для C
    _ => действия по-умолчанию
}

Ну не будеш же ты думать как о паттерне, скажем, о switch-е или if-е?

IT> Но сам паттерн никуда не девается.

Да, в том то и дело что девался! Он просто стал не нужен. Нет задачи кторую нужно им решать! Неужели это не очевидно?!

Поттерн решает некую задачу. Это стандартное решение для часто встречающихся задач. И если задачи эти больше решать не надо, то и паттерн теряет смысл.

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

IT> Я, например, склонен относить к паттернам даже такие вещи как наследование и инкапсуляцию.

И зря. Потому что они явно реализованы в ООЯ. А вот в С это действительно будет паттерн. В ООЯ я выражаю наследование настолько просто, что мне не нужно думать о нем как о паттерне: "class A : B { }" все! А вот на С я обязан буду надолбить кучу кода и решить ряд не тривильных задач. Тут паттерн очень нужен, так как до всех тонкостей нужно еще додуматься.

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

В общем, это уже скорее терминалогический спор.

IT> И что с того, что они встроены в языки и про них написана куча толстых книжек? Мне пофиг, для меня это лишь хорошие шаблоны, используемые мной в качестве элементов моего дизайна. Типовые идеи и типовые решения проблем.

Да то что они попросту не нужны.

Короче, ИТ, ответь на простой вопрос. Нафига мне Посетитель если те же задачи я могу решить проще и эффективнее?

VD>>Так как то что получается с помощью "стандартного решения и солашений по именованию" нманого менее удобно и более трудоемко чем стандартная возможность языка которая ко всему прочему являюется куда более универсальным решением.

IT>С этим никто не спорит. Спорят тут с тем, что ты неверно для себя сформулировал понятие паттерн проектирования

Я его не формулировал. Ты и сам его привел — "repeatable solution to a commonly-occurring problem in software design". Так вот я просто говорю о том, что если у меня нет проблем, то и выражать их в виде паттерна мне не нужно.

IT>и совершенно необоснованно ограничил его примерами из книжки GOF.

Ну, извини GoF ввели этот термин. К тому же твое определение мало чем отличается. Важно то, что паттерн — подразумевает проблему и решение. А я уже устал повторять, что есть языки для которых проблемы решаемые некоторыми паттернами выглядят просто смешно. Эти паттерны прикрывают недостатки языков в которых одни были придуманы. И думать ими просто глупо если есть более простые и эффективные решения.

VD>>Вот что отличает возможность языка от паттерна проектирования.

IT>Эти вещи нельзя сравнивать. От реализации паттерна средствами языка, паттерн не исчезает. Он просто реализуется средствами языка.

Ну, повторяться 25-ый раз я пожалуй не буду. См. выше.

VD>>Мне не нужно уже оперировать понятием паттернв в языке где есть нужные возможности.

IT>Оперировать понятиями паттерн нужно всегда, только не так как это делаешь ты. Паттерн — это типовое решение определённой задачи, выявленный и сформированный подход к решнию повторяющихся задач дизайна приложения.

Мне ответят на вопрос? Зачем мне типовоер решение для тривильных задач? Зачем мне типовое решение для операции сложения? Зачем мне типовое решение для условного перехода? Я могу думать о задаче проще и я буду это делать. Паттерн устраняет сложность, а если нет сложности, то нет... Хотя опять повторяюсь.

IT>Да-да, я знаю о чём ты подумал И я с тобой полностью в этом согласен.

Я рад, что ты подумал о том о том, что я подумал, о том о чем подумал ты. И я согласен, что паттерны можно автоматизировать. Но я то говорил все же о другом. Жаль что ты присоеденился к группе Блабл-программистов которе смотрят на проблемы только с известных им колоколен. Меж тем мир шире и многогранее.

IT> Немерле как раз то самое средство. Именно в этом я вижу его наибольшую ценность. Библиотеки макросов Немерле — это ни что иное как библиотеки паттернов.

Немерле еще к тому еж и язык в котром изначально больше средств. И именно это дает возможность ему напрочь отказаться от многих паттернов необъодимых в современных ООЯ. Но это не его заслуга. Он просто грамотно впитал в себя более высокоуровневые и мощьные конструкции.

Меня отровенно радуют некоторые случаи в которых макаронный код получается переписать кратче и понятнее. Вот например такой код:

internal set_unparsed_state () : void
{
    mutable fileList : list[string * string] = [];

    foreach (file in sources)
        match (file.Value)
        {
        | Parsed as p => fileList ::= (file.Key, p.code);
        | _ => ();
        }

    foreach (item in fileList)
        sources [item [0]] = ParsedFile.NotParsed (item [1]);
}

я с большим удовольствием переписал так:

internal set_unparsed_state () : void
{
    foreach ((fileName, Parsed(_, code)) in _sources.KeyValuePairs)
        _sources[fileName] = ParsedFile.NotParsed(code);
}

А вот такой же код на C# (декомпиляция предыдущего варианта подправленная для читаемости):

internal void set_unparsed_state()
{
  foreach (Tuple<string, ParsedFile> elem in this._sources.KeyValuePairs)
  {
    if (elem.field1 is ParsedFile.Parsed)
    {
      string code = ((ParsedFile.Parsed) elem.field1).code;
      this._sources[elem.field0] = new ParsedFile.NotParsed(code);
    }
  }
}

Точнее это я уже распознал один паттерн. Декомпилированный код был таким:

internal void set_unparsed_state()
{
  Tuple<string, ParsedFile>[] cached_collection = this._sources.KeyValuePairs;
  for (int i = 0; i < cached_collection.Length; i++)
  {
    Tuple<string, ParsedFile> elem = cached_collection[i];
    if (elem.field1 is ParsedFile.Parsed)
    {
      string code = ((ParsedFile.Parsed) elem.field1).code;
      this._sources[elem.field0] = new ParsedFile.NotParsed(code);
    }
  }
}

Вот и спрашивается нафига мне выглядывать паттерны в макаронном коде когда я могу исходно думать более высокоуровневыми конструкциями.

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

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

VD>>>Покажи мне хотя бы один Посетитель в парсере созданном на ФЯ.

FR>>Покажи мне там же хоть один объект.

VD>http://nemerle.org/svn/nemerle/trunk/ncc/passes.n

VD>Твой ход.

Для парсера на ФЯ там слишком много internal mutable

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

VD>>>>>Это только по-твоему.
IT>>>>По-моему тоже.
VD>>>Ну, и зря.
IT>>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.
VD>В столь конструктивной беседе могу только продолжить ряд — не правильно.

Продолжаем — это твоё заблуждение

IT>>Вот правильная ссылка Design pattern (computer science)
IT>>

In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design.

VD>Что в лоб, что полбу. Смысл не изменяется.

Очень даже изменяется. Судя по твоей ссылке, для тебя паттерн — это один из перечисленных в книжке паттернов. Это — заблуждение. Паттерн — более широкое понятие.

IT>>От того что некоторые паттерны непосредтственно реализуются языковыми конструкциями они не перестают быть паттернами.

VD>Перестают. Они перестают быть "repeatable solution". Они превращаются в синтаксис языка. К тому же речь не идет о тупом переносе паттернов в язык. Речь идет о создании более высокоуровневых решений.

А языковые решения ты используешь не как "repeatable solution"?

IT>> Те 26 (или сколько их там) паттернов из книжки GOF — это не все возможные паттерны, это лишь их небольшое множество.

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

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

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

VD>Всякая иделогия вгоняет в свои рамки. Ты слишком погрузился в рамки паттернов.

Какая ещё идеология, какие рамки? Я просто называю вещи своими именами.

VD>Оторвись от нее и просто скажи будешь ли ты мыслить паттернами описывая арефмитическое выражение, например?

В арифметических выражениях тоже можно выявлять паттерны, но эти паттерны не являются паттернами проектирования.

VD>Вот и я говорю о том, что в зависимости от языка ты будешь выделять разный набор паттернов. Те что нужны в одном языке окажуется совсем бессмысленными в другом. В ассемблере для тебя даже if — это паттерн. А в каком нибудь Немерле тебе не нужны даже Посетители.

Ты путаешь понятие паттерна и его реализации. Попытайся это понять.

VD>Ну не будеш же ты думать как о паттерне, скажем, о switch-е или if-е?

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

IT>> Но сам паттерн никуда не девается.
VD>Да, в том то и дело что девался! Он просто стал не нужен. Нет задачи кторую нужно им решать! Неужели это не очевидно?!

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

VD>Поттерн решает некую задачу. Это стандартное решение для часто встречающихся задач. И если задачи эти больше решать не надо, то и паттерн теряет смысл.

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

IT>> Я, например, склонен относить к паттернам даже такие вещи как наследование и инкапсуляцию.

VD>И зря. Потому что они явно реализованы в ООЯ. А вот в С это действительно будет паттерн.

Я же говорю, ты путаешь понятия паттерн и реализация паттерна.

VD>Короче, ИТ, ответь на простой вопрос. Нафига мне Посетитель если те же задачи я могу решить проще и эффективнее?

Решай, кто тебе не даёт Речь ведь не об этом.

IT>>С этим никто не спорит. Спорят тут с тем, что ты неверно для себя сформулировал понятие паттерн проектирования

VD>Я его не формулировал. Ты и сам его привел — "repeatable solution to a commonly-occurring problem in software design". Так вот я просто говорю о том, что если у меня нет проблем, то и выражать их в виде паттерна мне не нужно.

Если паттерн уже выражен другими средствами, то, конечно, не нужно.

IT>>и совершенно необоснованно ограничил его примерами из книжки GOF.

VD>Ну, извини GoF ввели этот термин.

Но они нигде не утверждали, что паттерн — это только то, что описано у них в книжке.

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

ГВ>> А мы до тех пор будем считать истинным утверждение, что фобии и фанатическая ненависть (или паче чаяния — привязанность?) — у тебя. И от такого славного персонажа, богатого фобиями и ненавистью я вполне принимаю обвинения в том, что не умею пользоваться C++.

VD>Ну, это понты и пустословье. Оставим это.

Не уходи от ответа. Ну так что, обоюдно укорачиваем языки? Ты — на "фобии", "фанатизм" и прочее подобное, я — на ответные обвинения в паталогической неспособности к C++ (сиречь — необоснованные обвинения в некомпетености)? Ы?

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

label1:

VD>>>>>>Это только по-твоему.
IT>>>>>По-моему тоже.
VD>>>>Ну, и зря.
IT>>>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.
VD>>В столь конструктивной беседе могу только продолжить ряд — не правильно.

IT>Продолжаем — это твоё заблуждение

goto label1; // :)

IT>Очень даже изменяется. Судя по твоей ссылке, для тебя паттерн — это один из перечисленных в книжке паттернов.

Тебе показалось. Просто это перво что нашлось.

IT>А языковые решения ты используешь не как "repeatable solution"?

Естественно. Я ими мысли выражаю. И при этом мне не нужно думать о том, что мысл можно выразить по разному и что эту мысл прийдется распозновать в коде.

label2:

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

IT>Ещё раз попытайся понять то, что я уже устал повторять.

А ты не повторяй. Я и с первого раза неплохо слышу.

IT> Паттерн, реализованный средствами языка и/или среды выполнения не перестаёт быть паттерном. Ты его как использовал раньше, так и используешь сейчас, только теперь это встроено в язык или в среду и, я вполне допускаю, что его теперь гораздо удобнее использовать, т.к. не надо каждый раз реализовывать вручную.

Извини, но еще раз:

goto label2; // просьба вникнуль в написанное.

IT>Какая ещё идеология, какие рамки? Я просто называю вещи своими именами.

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

IT>В арифметических выражениях тоже можно выявлять паттерны,

Нет, нет. Речь не о паттернах в выражениях. А о самих выражениях. Ну, там паттерн сложения. Или паттерн деления.

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

А чем собственно сложение отличается от оперетора switch?


VD>>Ну не будеш же ты думать как о паттерне, скажем, о switch-е или if-е?

IT>Как о паттерне проектирования? Вряд ли. Как о паттерне вообще, конечно же буду. Просто центр принятия решения об использовании этих паттернов у меня уже давно находится не в голове, а на кончиках пальцев.

Ну, вот и славненко. Теперь осталось только понять, что switch от match отличается только тем, что match делает ненужным применение паттернов вроде Посетителя.

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

Паттерны проектирования ведь в первую очередь нужны для понимания между людьми. Думаю, ты и раньше (до ГоФ) применял разные паттерны незадумываясь о том, что это паттерн. А ГоФ предожили дать им имена. Это позволяет мне только произнести к примеру Фабрика или Посетитель и ты понимашь в общих чертах о каком примере я говорю. Так вот имея паттерн-матчинг просто нет смыла говорить Посетител. Он вообще не нужен, так как то зачем он предназначен решается применением одного единственного универсального оператора. Еще глупее будет говорить паттерн "match". Ведь это оператор. И нет проблем говорить "оператор match".

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

Так что я все же остаюсь при своем мнении.

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

VD>>http://nemerle.org/svn/nemerle/trunk/ncc/passes.n

VD>>Твой ход.

FR>Для парсера на ФЯ там слишком много internal mutable

И тем неменее это парсер на ФЯ в котором нет ни одного Посетителя и от этого только проще становится. Так что ход неудачный. Гейм овер.

А вообще свои догмы нужно разрушать. Чистых ФЯ практически нет. Хаскель, Схема... что там еще? Все остальные ФЯ поддерживают императивные возможности, но ФЯ от этого быть не перестают.

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

ГВ>Не уходи от ответа. Ну так что, обоюдно укорачиваем языки? Ты — на "фобии", "фанатизм" и прочее подобное, я — на ответные обвинения в паталогической неспособности к C++ (сиречь — необоснованные обвинения в некомпетености)? Ы?

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

А что до фобий. Что вижу о том и говорю. Если вижу ничем не оправданные домыслы и паталогическую боязнь чего-то то и говорю — фобии.

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

VD>

VD>label1:
VD>

VD>>>>>>>Это только по-твоему.
IT>>>>>>По-моему тоже.
VD>>>>>Ну, и зря.
IT>>>>Это не то, чтобы "и зря", это не только не зря, это просто — правильно.
VD>>>В столь конструктивной беседе могу только продолжить ряд — не правильно.

IT>>Продолжаем — это твоё заблуждение
VD>

VD>goto label1; // :)
VD>

Почему goto, а не функция с концевой рекурсией?

VD>

VD>label2:
VD>

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

VD>Извини, но еще раз:
VD>

VD>goto label2; // просьба вникнуль в написанное.
VD>

Сколько раз вникаю, столько раз и вижу, что ты путаешь понятия паттерн и реализация паттерна.

VD>Нет. Ты начианашь называть и другие вещи одним и тем же именем.

Какие такие другие вещи?

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

Если очень узко трактовать, то получается, что паттерны — это только то, что описали GoF в своей книжке.

IT>>В арифметических выражениях тоже можно выявлять паттерны,

VD>Нет, нет. Речь не о паттернах в выражениях. А о самих выражениях. Ну, там паттерн сложения. Или паттерн деления.

Не пойму причём тут операции

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

VD>А чем собственно сложение отличается от оперетора switch?

В каком плане?

IT>>Как о паттерне проектирования? Вряд ли. Как о паттерне вообще, конечно же буду. Просто центр принятия решения об использовании этих паттернов у меня уже давно находится не в голове, а на кончиках пальцев.

VD>Ну, вот и славненко. Теперь осталось только понять, что switch от match отличается только тем, что match делает ненужным применение паттернов вроде Посетителя.

Да мне всё равно чем отличается switch от match. А то, что им очень удобно реализуется паттерн вроде посетителя так это вообще здорово.

VD>Паттерны проектирования ведь в первую очередь нужны для понимания между людьми.

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

VD>Так что я все же остаюсь при своем мнении.

OK.