Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Набирать ключевые слова большими буквами противоестественно

СГ>ЭТО ВСЕГО ЛИШЬ ВОПРОС ПРИВЫЧКИ.

угу. капс лок зажал — и вперед 10 страниц большими буквами.
Ты не ответил на мое замечание. вообще.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>>Набирать ключевые слова большими буквами противоестественно

СГ>>ЭТО ВСЕГО ЛИШЬ ВОПРОС ПРИВЫЧКИ.

ЗХ>угу. капс лок зажал — и вперед 10 страниц большими буквами.
ЗХ>Ты не ответил на мое замечание. вообще.

Отвечу я. Здесь явное издевательство с моей стороны, не спорю НО обратите внимание, что произойдет при зажатом капслоке. Добавлю. А что, если разные программисты по-разному раскрашивают свой код?

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

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

S>> Exit это выход из процедуры.

VD>Ну, здесь я может ошибаюсь. Давно не возился с разными Дельфями. Но в Паскле вообще небыло средства прервать управление.

S>> А Continue и Break еще во 2 Delphi были

VD>Дельфи к Паскалю имеет отдаленное отношение.
Ты немного противоречишь САМ СЕБЕ.
VD>Ну, не просто так в Яве и Шарпе остались continue и есть return. Та же Дельфи и Васик долго жили без них, но в итоге иVD> в них были добавлены эти конструкции. Вред этих конструкций высасан из пальца.
Так, что и тебя понять очень сложно
Всетаки не надо задевать огульно Delphi там, где его не знаешь . А уж тем более ставить его в один ряд с Васиком, хотя к Васику у меня нет никаких претензий особенно фор Аппликатион, просто совершенно разные языки.
Тогда лучше сравнивать ранний Паскаль с Ранним С. Во интересных сравнений найдется огромная куча.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Тем хуже для оберона. Набирать ключевые слова большими буквами противоестественно (все время зажимать шифт или дергать капс лок). Костыли, встроенные в BlackBox (клавиатурная комбинация для смены регистра последнего слова) — всего лишь костыли.
ЗХ>Об этом при проектировании языка никто не задумался?

Да фиолетово Оберону. В IDE для языка Modula-2 от фирмы TopSpeed ключевые слова поднимались в верхний регистр при нажатии на пробел после ключевого слова. Поскольку почти всегда после ключевого слова требуется пробел, то это происходило автоматически и было очень удобно.

Кстати, в Zonnon'e изначально ключевые слова тоже были в верхнем регистре, но потом синтаксис пересмотрели и решили, чтоб они были в нижнем.

Здравствуйте, Павел Кузнецов, Вы писали:

>> Скорее всего тут проблемы в понимании приципов ООП.

ПК>No comment.

А кстати, зря. Так как именно тут у нас основное разногласие.

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

AndrewVK:

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

> Дотнет умеет при помощи TransparentProxy, но ценой заметной потери производительности.

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

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

// Класс, которому будем делегировать.
class A
{
   public void a() { }
   public void b() { }
};

// Класс, который делегирует
class B
{
   // Явное делегирование
   public void a() { a_.a(); }

   // Какая-то "магия" c TransparentProxy, чтобы остальные методы тоже делегировались.
   // . . .

   private A a_;
};

Будет ли в данном случае потеря производительности при вызове обоих методов, a() и b(), через интерфейс класса B, или же только при вызове b(), который делегируется неявно?

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

VD>Специльно не поскипал твою тираду. Так где из всех этих метс я перешел к навазыванию "такого расположения функции sort"? Зачем столько слов? Может быть просто признать тот факт, что это ты пыташся выдать свое мнение за единстванно верное и тем самым навязать его, а я все го лишь говорю, что считаю иначе?

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

В самом деле, цитировать довольно объёмные бумажки по OCP, LSP и т.п. в форуме довольно затруднительно, поскольку цитирование неизбежно будет в той или иной степени вырванным из контекста и вызовет ещё более бурное флеймогонство и "ниспровержение авторитетов".

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

V>>

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

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

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

Sinclair:

> ПК> Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов Вот пример такого, с позволения сказать, класса: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Arrays.html — ни состояния, ни поведения, ни инвариантов

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

Ага, точно.

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

Имхо, авторы Java в вынесении Sort() за пределы Array как раз ближе к "классике" ООП, нежели Влад. Но это, естественно, очень сильно зависит от точки зрения.

> По поводу свободных процедур у меня возникают некоторые сомнения. Дело в том, что с точки зрения ООП все должно быть объектом.

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

> Я бы выделил методы типа Sort в специальные объекты, реализующие некоторые алгоритмы. Примерно так:

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

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

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

> Изменить язык и дать возможность вносить фиксированные реализации методов в интерфейсы. Хотя бы статиков. Тогда мы могли бы записать все, что нам нужно, в интерфейс для source, и жить себе не тужить.

Забавно, что в C++ рассматривается предложение, которое позволит убить всех подобных зайцев сразу: разрешить синтаксис a.foo() для вызова "свободных" функций, если в классе, объектом которого является a, нет фунции foo(). Впрочем, будет ли оно принято, и каковы реальные последствия такого шага, пока не ясно... Но направление мыслей достаточно похожее.

> Оставить язык в покое и сделать более продвинутый редактор. Например, при помощи атрибутов расширять CodeCompletion.

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

Sinclair:

> ПК>

Date и String
> DateConverter: TypeConverter.

Возражений нет.

> ПК>

1) целого в строку; 2) строки в целое?
> IntConverter: TypeConverter.

То же самое.

> ПК>

суммы/разницы двух дат, суммы/разницы двух DateDifference, суммы Date и DateDifference?
> Возможно, Calendar?

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

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

Posted via RSDN NNTP Server 1.9 gamma

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Забавно, что в C++ рассматривается предложение, которое позволит убить всех подобных зайцев сразу: разрешить синтаксис a.foo() для вызова "свободных" функций, если в классе, объектом которого является a, нет фунции foo(). Впрочем, будет ли оно принято, и каковы реальные последствия такого шага, пока не ясно... Но направление мыслей достаточно похожее.

Этакая инфиксная нотация. a.foo(b,c,...z) <--> A::foo(a,b,c,...z) ?
Круто.
Там, глядишь, и до карринга доберёмся. И до ленивых вычислений.

Undying:

>>> Внешняя функция сортировки нарушает инкапсуляцию коллекции, т.к. ее использование означает явное указание метода сортировки.

> ПК>Не обязательно:
> ПК>

> ПК>class Collection1;
> ПК>class Collection2;

> ПК>void sort(Collection1&);
> ПК>void sort(Collection2&);
> ПК>

> Этот финт ушами проходит только в том случае, если мы работаем с конкретными типами коллекций, не скрытыми за интерфейсами, что сам понимаешь в общем случае нехорошо.

Так... Я уже совсем запутался. Ранее предлагалось добавлять sort() именно в конкретные типы, от которых никто не будет наследоваться. В случае, если мы работаем через интерфейсы, эти функции нам вообще доступны не будут.

Если же некоторая функция является "основной" для некоторого класса, определяющей его поведение, никаких возражений против того, чтобы она была вынесена в тот или иной интерфейс, реализуемый данным классом, у меня нет. Единственное, я не согласен, что Array.sort() относится к последнему случаю.

AndrewVK:

> <...> чем такой вариант:
>

> public interface ISortable
> {
>     void Sort();
> }
>
> public class SomeList : IList, ISortable
> {
>     ...
>     public void Sort() {...}
> }
>
> ...
> someListInstance.Sort();
>

>
> хуже такого:

По-моему, ниже опечатка, и ISupportSort от IList унаследован быть не должен.

>

> public interface ISupportSort : IList
> {
>     int CompareElements(int index1, int index2);
>     void Exchange(int index1, int index2);
> }
>
> public class SomeList : IList, ISupportSort
> {
>     ...
>     int ISupportSort.CompareElements(int index1, int index2) {}
>     void ISupportSort.Exchange(int index1, int index2) {}
> }
>
> ...
> SomeSortFunction(someListInstance);
>

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

Первый вариант хуже по нескольким причинам:

Сортировка не является основной функциональностью SomeList

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

В частности:

Сохраняется ли в результате сортировки порядок элементов, для которых CompareElements возвращает 0 (т.е. они "равны" с точки зрения функции сравнения). Для некоторых использований это является критичным моментом.

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

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

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

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

Есть множество аналогичных алгоритмов, которые нужны пользователю

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

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

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

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

Повторное использование алгоритмов

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

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

В первом случае у разработчиков библиотеки никакой объективной потребности предоставлять алгоритмы в "отдельном" виде нет, а если они и пошли на этот шаг "доброй воли", то алгоритмы пользователя, аналогичные "библиотечным", к "библиотечным" классам применяться не смогут.

Расширяемость множества алгоритмов

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

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

Никаких из этих проблем не возникает, если "вспомогательные" алгоритмы (то есть не основные для самого класса, в данном случае SomeList) будут вынесены за пределы класса.

Posted via RSDN NNTP Server 1.9 gamma

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Так... Я уже совсем запутался. Ранее предлагалось добавлять sort() именно в конкретные типы, от которых никто не будет наследоваться. В случае, если мы работаем через интерфейсы, эти функции нам вообще доступны не будут.

Где я такое говорил? Так сделано в System.Collection, в принципе там это допустимо, т.к. на практике вроде бы не мешает, но в общем случае в подобных ситуациях должен вводится дополнительный интерфейс (ISort в данном случае), с которым и должен работать внешний код, понятно, что в этом случае имитировать полиформизм перегрузкой функций не удастся.

Здравствуйте, Павел Кузнецов, Вы писали:

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

+1

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

Например, заменить пузырьковую сортировку быстрой. Кроме того можно использовать и StableSort, если знание о стабильности будет использоваться только внутри объекта реализующего сортировку. В-третьих, можно заменить сортировку на какую-то хитрую, для которой стандартного IComparer'а недостаточно. Пример, первоначально мы сортировали, допустим, детали по названию в алфавитном порядке. Затем возникло требование, что детали должны выводится не в алфавитном порядке, а в каком-то привычном, который задает пользователь. Что ты будешь делать в данном случае, если сортировка производится внешними функциями?

Кстати, в stl какой механизм используется для указания того каким образом сравниваются два элемента?

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

ПК>Предложенная ранее альтернатива (изменить семантику метода класса) мне не кажется более удачной.

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

>> ПК> Естественно, если все было спроектировано на совесть, дублирования аналогичных вызовов Array.sort быть не должно, т.к. доступ к некоторому Array должен контролироваться одним классом <...>
>>
>> Вот это не понял, можно пояснить мысль примером.

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

Надеюсь, объяснил.

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

Да, согласен, в данном контексте я здесь не прав.

>> Но "Мы" опять же объект, а не функция.

ПК>"Мы" — да, "толкнем" — нет: если всем подряд приходится "толкать шарик", вовсе не факт, что хорошим решением является наследование их всех от какого-то общего класса только для того, чтобы выполнять какое-то действие с внешним объектом.

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

ПК>Дык, я как раз пытаюсь добиться внятного ответа, где же по мнению тех, кто помещает sort() в Array лежит та граница... Влад выдвинул критерий модификации объекта, согласно которому подобные функции должны будут включаться в интерфейс шарика.

Четкой границы естественно нет, это же не серебрянная пуля. Обычно есть возможность поместить эту функцию в несколько объектов (в случае одного объекта, есть возможность добавить объект), поэтому в каждом конкретном случае нужно разбираться помещение в какой именно объект будет оптимальным.

ПК>Естественно, не пишу, т.к. это не соответствует "моему" подходу. "Мой" подход — в том, чтобы помещать в интерфейс класса те функции, которые необходимы для обеспечения сохранности инвариантов класса (плюс устойчивость к изменениям реализации, но это уже другой разговор). Соответственно, работа с данными напрямую такому критерию не отвечает.

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

ПК>Рефакторинг я очень люблю и уважаю. Но для "внутренних" проектов, где весь код находится под контролем разработчиков. И с определенными ограничениями. Для библиотек же, "торчащих" наружу, я больше люблю и уважаю обратную совместимость.

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

VladD2:

>>> Скорее всего тут проблемы в понимании приципов ООП.

> ПК> No comment.

> А кстати, зря. Так как именно тут у нас основное разногласие.

Дык, имхо, это уже давно понятно Но чего теперь попусту воздух сотрясать, если мы вряд ли сможем повлиять на мнение оппонента?

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

Смотрел я когда-то на него. Как скриптовый язык хорош. Для написания больших систем — вряд ли. Можно ограничиться одним моментом:

In Ruby, classes are never closed: you can always add methods to an existing class.

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

Undying:

> Где я такое говорил?

Приношу извинения, это Влад говорил

> в общем случае в подобных ситуациях должен вводится дополнительный интерфейс (ISort в данном случае), с которым и должен работать внешний код, понятно, что в этом случае имитировать полиформизм перегрузкой функций не удастся.

Чтобы не повторяться, вот мой ответ Андрею на очень похожее сообщение: http://rsdn.ru/Forum/Message.aspx?mid=880991&amp;only=1

Автор: Павел Кузнецов
Дата: 02.11.04

alexeiz,

>

> template < typename Iter >
> int generic_sum( Iter begin, Iter end )
> {
>     int sum = 0;
>     for ( ; begin != end; ++begin )
>         sum += atoi( *begin );
>     return sum;
> }
>

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

Отчего же... Достаточно ввести соответствующий функтор, плюс запихать generic_sum в "класс":

class GenericSummator
{
public:
   template < typename Iter, typename F >
   static int generic_sum( Iter begin, Iter end, F f )
   {
     int sum = 0;
     for ( ; begin != end; ++begin )
         sum += f( *begin ); // здесь мы предполагаем, что язык позволяет переопределять в классе функтора
                             // operator(), или предоставляет какую-нибудь эквивалентную замену типа делегатов
     return sum;
   }
};

Конечно, чуть многословнее, и "концептуально грязнее", но вполне работоспособно...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>P.S. Но одна проблема с обертками, раз имеется в виду не наследование, все-таки, есть: если язык не поддерживает автоматическое делегирование (*), то каждый раз, когда в Array будет добавляться новый метод, надо будет модифицировать Wrapper.

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

ПК>Ситуация еще осложнится, если между нашим Wrapper'ом, и Array будет еще один-два слоя "библиотечных" оберток Wrapper1, Wrapper2 etc., добавляющих дополнительные, нужные нам "утилиты". Эти обертки неизбежно будут "запаздывать" за расширением Array, и в результате, если они не "выдают" Array наружу (**), наш Wrapper утилитами, добавленными в Array, пользоваться не сможет.

Это увеличит объем ручной работы, но принципиально ситуация не меняется.

ПК>(**) Что, со строгой точки зрения, если бы обертки были бы "полноценными" классами, уж точно являлось бы нарушением инкапсуляции, с которым, впрочем, при таком дизайне, наверное, приходится мириться Правда, с другой стороны, обертки "полноценными" классами, наверное, не являются в том смысле, что никакие новые сущности они собой не олицетворяют, и инварианты их, по идее, совпадают с инвариантами Array, так что, наверное, применительно к ним о нарушении инкапсуляции, вообще, говорить бесмысленно, т.к. они по сути ничего и не инкапсулируют... Или нет? По-моему, обертки, предназначенные только для добавления вспомогательных функций, и выдающие свои "потроха" наружу, в классическое ООП вообще слабо вписываются...

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

Кодт,

> Этакая инфиксная нотация. a.foo(b,c,...z) <--> A::foo(a,b,c,...z) ?

Ага: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1585.pdf Но, судя по предварительным голосованиям, обсуждаемая здесь возможность, то есть вызов "свободных" функций через синтаксис функций-членов, пока особой поддержки в комитете не получила; скорее могут ограничиться разрешением вызова функций-членов через синтаксис "свободных" функций, если вообще какие-то изменения будут. В общем, поживем-увидим.