Что такое SuperPuperA?
Если это класс, то цель (избежать привязки к конкретным классам) не достигнута.
Если это переменная, то налицо паттерн, использование которого и на Си++ выразится одной строчкой:
A *a = afp->CreateA();
Не вижу, каким образом динамический язык позволяет здесь обойтись без паттерна.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[10]: Паттерны суть слабости языков программирования
AVC>Что такое SuperPuperA? AVC>Если это класс, то цель (избежать привязки к конкретным классам) не достигнута. AVC>Если это переменная, то налицо паттерн, использование которого и на Си++ выразится одной строчкой:
Блин, ну определи чётко цель-то! Что и как происходит? Уже конкретно достало паттерн Сфероконь обсуждать
Re[11]: Паттерны суть слабости языков программирования
Здравствуйте, Курилка, Вы писали:
AVC>>Что такое SuperPuperA? AVC>>Если это класс, то цель (избежать привязки к конкретным классам) не достигнута. AVC>>Если это переменная, то налицо паттерн, использование которого и на Си++ выразится одной строчкой:
К>Блин, ну определи чётко цель-то! Что и как происходит? Уже конкретно достало паттерн Сфероконь обсуждать
Паттерн Сфероконь пока что обсуждаешь только ты с VladD2.
Я говорю о хорошо известном паттерне Абстрактная Фабрика из книжки GoF.
Если ты вдруг запамятовал, что это такое и для чего используется, загляни в книжку.
А если не запамятовал, то к чему рассуждения о Сфероконях?
А цель простая.
Хочу, чтобы мне показали как можно обойтись без порождающих паттернов (в смысле GoF), одними средствами языка (например, с динамической типизацией).
Потому как в статье, которую ты вынес на обсуждение в этом топике, резюме, ИМХО, достаточно резкое:
Patterns are signs of weakness in programming languages.
When we identify and document one, that should not be the end of the story. Rather, we should have the long-term goal of trying to understand how to improve the language so that the pattern becomes invisible or unnecessary.
Вот я и хочу испытать, ко всем ли паттернам применим этот тезис.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[12]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Курилка, Вы писали:
AVC>>>Что такое SuperPuperA? AVC>>>Если это класс, то цель (избежать привязки к конкретным классам) не достигнута. AVC>>>Если это переменная, то налицо паттерн, использование которого и на Си++ выразится одной строчкой:
К>>Блин, ну определи чётко цель-то! Что и как происходит? Уже конкретно достало паттерн Сфероконь обсуждать
AVC>Паттерн Сфероконь пока что обсуждаешь только ты с VladD2. AVC>Я говорю о хорошо известном паттерне Абстрактная Фабрика из книжки GoF.
В GoF как раз написано что паттерн абстрактная фабрика в смаллтоке мало полезен, и легко реализуется через патерн прототип
Вообще для языков с утиной типизацией абстрактная фабрика просто вырождается в реализации конкретных фабрик, в абстрактной же фабрике никакой необходимости нет.
Re[13]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
AVC>>Я говорю о хорошо известном паттерне Абстрактная Фабрика из книжки GoF.
FR>В GoF как раз написано что паттерн абстрактная фабрика в смаллтоке мало полезен, и легко реализуется через патерн прототип FR>Вообще для языков с утиной типизацией абстрактная фабрика просто вырождается в реализации конкретных фабрик, в абстрактной же фабрике никакой необходимости нет.
Насколько я помню, в GoF говорится о том, что в Смоллтоке необязательно создавать класс для каждой отдельной абстрактной фабрики.
В Смоллтоке сама фабрика может быть создана с помощью паттерна Прототип.
Полезность самой фабрики под сомнение, вроде бы, там не ставится.
Т.е. в Смоллтоке получается двойное использование паттернов: Абстрактная Фабрика, которая, в свою очередь, создается с помощью паттерна Прототип.
(Кстати, в первоначальном Обероне для создания фабрики новый класс также не потребовался бы. )
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[14]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Полезность самой фабрики под сомнение, вроде бы, там не ставится.
Так я тоже не ставлю под сомнение полезность паттернов, их конечно нужно знать. Но очень большая часть паттернов в динамических языках (и в функциональщине) скажем так реализуется или тривиально, или близко к этому. Поэтому их важность для таких языков гораздо ниже чем для для традиционных (статических) императивных языков.
AVC>Т.е. в Смоллтоке получается двойное использование паттернов: Абстрактная Фабрика, которая, в свою очередь, создается с помощью паттерна Прототип.
Там очень многие паттерны также вырождаются.
AVC>(Кстати, в первоначальном Обероне для создания фабрики новый класс также не потребовался бы. )
Почему?
Re[15]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
AVC>>Т.е. в Смоллтоке получается двойное использование паттернов: Абстрактная Фабрика, которая, в свою очередь, создается с помощью паттерна Прототип.
FR>Там очень многие паттерны также вырождаются.
Но не исчезают.
AVC>>(Кстати, в первоначальном Обероне для создания фабрики новый класс также не потребовался бы. )
FR>Почему?
Из-за особенностей поддержки ООП в Обероне.
Собственно, вполне правильно будет сказать, что в Обероне-1 не было классов.
Тип-запись в Обероне не является единицей инкапсуляции (такой единицей является модуль), "методы" в О-1 представлены обычными процедурными переменными, и между ними и записью нет прямой синтаксической связи.
Поэтому любой "метод" можно заменить на ходу просто переустановкой процедурной переменной.
Т.к. абстрактная фабрика обыкновенно есть просто набор "порождающих" методов, то вполне можно поменять процедурные переменные, не определяя новых классов.
Так что здесь все просто.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[10]: Паттерны суть слабости языков программирования
VD>Я вот, например, не имею машину и не хочу ее иметь. Причем с деньгами у меня все впорядке. Просто она мне не нужна. У меня работа в 10 минутах хотьбы. Спортзал тоже. А если
ИМХО только это уже показывает что ты о ней задумываешься?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[16]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FR, Вы писали:
AVC>>>Т.е. в Смоллтоке получается двойное использование паттернов: Абстрактная Фабрика, которая, в свою очередь, создается с помощью паттерна Прототип.
FR>>Там очень многие паттерны также вырождаются.
AVC>Но не исчезают.
Ну скажи, откуда ты это "исчезновение" придумал? Речь изначально шла о том, чтобы не писать заново и заново груды кода для реализации паттерна, т.е. использовать его, но написать при этом лишь достаточное число кода (т.е. тот код, который изменеятся при каждом использовании паттерна, и не повторять одни и те же части его)
Re[11]: Паттерны суть слабости языков программирования
Здравствуйте, ironwit, Вы писали:
VD>>Я вот, например, не имею машину и не хочу ее иметь. Причем с деньгами у меня все впорядке. Просто она мне не нужна. У меня работа в 10 минутах хотьбы. Спортзал тоже. А если I>ИМХО только это уже показывает что ты о ней задумываешься?
Я иногда о мышах и такраканах задумываюь. Что же мне из-за этого их заводить что ли?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Паттерны суть слабости языков программирования
Здравствуйте, Курилка, Вы писали:
К>Ну скажи, откуда ты это "исчезновение" придумал? Речь изначально шла о том, чтобы не писать заново и заново груды кода для реализации паттерна, т.е. использовать его, но написать при этом лишь достаточное число кода (т.е. тот код, который изменеятся при каждом использовании паттерна, и не повторять одни и те же части его)
Для этого динамика не ну нужна... Правильные статические языки тоже позволяют не писать одно и тоже кучу раз.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Паттерны суть слабости языков программирования
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Курилка, Вы писали:
К>>Ну скажи, откуда ты это "исчезновение" придумал? Речь изначально шла о том, чтобы не писать заново и заново груды кода для реализации паттерна, т.е. использовать его, но написать при этом лишь достаточное число кода (т.е. тот код, который изменеятся при каждом использовании паттерна, и не повторять одни и те же части его) WH>Для этого динамика не ну нужна... Правильные статические языки тоже позволяют не писать одно и тоже кучу раз.
Я где-то утверждал, что для этого обязательно нужна динамика? И расскажи, пожалуста, что такое "правильнось" статических языков
Re[13]: Паттерны суть слабости языков программирования
Здравствуйте, vdimas, Вы писали:
VD>>паттерн-матчинг нивилирует необходимость в этом паттерне. V>Это смотря сколько посещений надо сделать. Двойная диспечеризация работает быстрее всяких сравнений. И с чего ты взял что patterm-matching нельзя оптимизировать до двойной диспетчеризации в тех члучаях когда это возможно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Паттерны суть слабости языков программирования
V>>Это смотря сколько посещений надо сделать. Двойная диспечеризация работает быстрее всяких сравнений. WH> И с чего ты взял что patterm-matching нельзя оптимизировать до двойной диспетчеризации в тех члучаях когда это возможно?
Ну вот откомпили в Nemerle или еще где, и покажи нам в рефлекторе, до какого уровня там оптимизируется. Пока что я в имплементации паттерн-матчинга черти что видел. Расплату за удобства.
