Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата korvin @ 27.01.11, 19:40

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

Я такого не говорил. Я сказал, что возможен интерфейс "получить" и "установить". В каком виде пользователь получит что-то - в виде ссылки/указателя на константный экземпляр, или копии объекта, или ещё каким-то образом будет устранено нежелательное влияние - мне не важно. Мне важно, что я как разработчик класса узнаю об изменении по сообщению "установить", а не буду ловить хз сколько событий объекта, который я или разработчик класса-родителя имел неосторожность отдать наружу.

Цитата D_KEY @ 27.01.11, 19:40

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

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

Цитата --Ins-- @ 27.01.11, 19:43

Цитата D_KEY @ 27.01.11, 19:36

Что итераторы? Итераторы в С++ не встроены. Хотя указатели ими являются

Любой язык, имеющий оператор foreach, на уровне языка имеет поддерку итераторов. Так что плохого в том, что язык может иметь поддержку фабричных методов, к примеру?

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

Цитата

Зато велосипеды изобретать не нужно, колеса которых зачастую квадратные

А их и тут не нужно изобретать. Да и трудоемкость одинаковая. А абстрактные фабрики доступны в библиотеках.
Кстати, вот в стандартную библиотеку внести можно. В сам язык - какой смысл?

Добавлено 27.01.11, 19:50

Цитата korvin @ 27.01.11, 19:44

Цитата D_KEY @ 27.01.11, 19:40

Могу согласится с тем, что все согласно интерфейсу. Мне не ясно, почему в этом интерфейсе нельзя сказать, что модификация не допускается.

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

А если клиентам очень хочется знать значение, но не менять его?

Цитата

Цитата D_KEY @ 27.01.11, 19:40

А еще мне не нравится, что есть тип является классом, то поведение одно, а если нет, то другое.

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

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

Цитата Повстанець @ 27.01.11, 19:45

Да я не против. И не про это. Просто напоминает она мне старый добрый (больше старый, чем добрый) процедурно-модульный подход. Что не особо вписывается в утверждение о мощи объектной системы делфи.

эм... нет. с чего Вы решили?

Добавлено 27.01.11, 19:52

Цитата D_KEY @ 27.01.11, 19:48

только лишнии языковые конструкции

только в ущербных языках без метапрограммирования... =) если ты про ключевые слова

Сообщение отредактировано: korvin - 27.01.11, 19:53

Цитата korvin @ 27.01.11, 19:46

Цитата D_KEY @ 27.01.11, 19:40

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

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

Менять саму точку - нормально. Нормально ли меняя точку, менять состояние Rect в обход его интерфейса?
Я не говорю о правильности работы кода, написанного в таком стиле. То есть ты прав в том, что мы получили то, что в контракте прописали, но правилен ли сам подход?

И кстати, даже по контракту клиент не знает, приведет ли модификация переданной ему точки к модификации самого Rect'а.
Как об этом узнать?

Цитата D_KEY @ 27.01.11, 19:48

А если клиентам очень хочется знать значение, но не менять его?

если в значении поля мутабельный объект -- возвращай немутабельный

Цитата korvin @ 27.01.11, 19:50

Цитата D_KEY @ 27.01.11, 19:48

только лишнии языковые конструкции

только в ущербных языках без метапрограммирования... =) если ты про ключевые слова

Но мы и говорим о таком ущербном языке

Добавлено 27.01.11, 19:55

Цитата korvin @ 27.01.11, 19:46

проси у прямоугольника иммутабельную-точку

Да я не спорю. Только вот как?

Цитата D_KEY @ 27.01.11, 19:53

И кстати, даже по контракту клиент не знает, приведет ли модификация переданной ему точки к модификации самого Rect'а.
Как об этом узнать?

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

Добавлено 27.01.11, 20:03

Цитата D_KEY @ 27.01.11, 19:54

Но мы и говорим о таком ущербном языке

s/таком ущербном языке/таких ущербных языках/
их тут три в топике =)

Цитата D_KEY @ 27.01.11, 19:54

Да я не спорю. Только вот как?

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

Цитата korvin @ 27.01.11, 19:50

эм... нет. с чего Вы решили?

Простейшая задача. Яйца выеденного не стоит буквально на любом более-менее приличном ЯП. Имею 3 решения. Все 3 решения требуют реализации, а не объявления. И лишь одно из них не является контексто-зависимым. Как во времена моей молодости, на суровом С.

Цитата Повстанець @ 27.01.11, 20:04

Простейшая задача. Яйца выеденного не стоит буквально на любом более-менее приличном ЯП. Имею 3 решения. Все 3 решения требуют реализации, а не объявления. И лишь одно из них не является контексто-зависимым. Как во времена моей молодости, на суровом С.

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

Цитата korvin @ 27.01.11, 20:00

Цитата D_KEY @ 27.01.11, 19:53

И кстати, даже по контракту клиент не знает, приведет ли модификация переданной ему точки к модификации самого Rect'а.
Как об этом узнать?

документацию читать надо.

Код должен быть самодокументирован по максимому.

Цитата

как будто С++ может дать гарантию, что возвращает (неконстантную) ссылку на не сам объект, а копию, если разработчик класса не поставит const. более того, поскольку так писать судя по всему не принято в С++, то вряд ли ты будешь ожидать такого подвоха?

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

Добавлено 27.01.11, 20:11

Цитата korvin @ 27.01.11, 20:00

Цитата D_KEY @ 27.01.11, 19:54

Да я не спорю. Только вот как?

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

Так покажи, как это на Delphi. Из обсуждения я понял, что это не так просто, если Point - класс.

Цитата D_KEY @ 27.01.11, 20:08

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

ну дык так же и в делфи: если возвращаешь объект, значит хочешь, чтобы его могли изменить извне.

Цитата korvin @ 27.01.11, 20:13

ну дык так же и в делфи: если возвращаешь объект, значит хочешь, чтобы его могли изменить извне.

Только как в плюсах сказать, что мы не хотим его изменения, понятно. Не понятно, как это сделать на дельфи.

Цитата D_KEY @ 27.01.11, 20:08

Так покажи, как это на Delphi. Из обсуждения я понял, что это не так просто, если Point - класс.

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

1) вернуть копию;
2) изменить интерфейс TRect;
3) сделать класс TPoint иммутабельным.

Сообщение отредактировано: korvin - 27.01.11, 20:19

Цитата korvin @ 27.01.11, 20:13

Цитата D_KEY @ 27.01.11, 20:08

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

ну дык так же и в делфи: если возвращаешь объект, значит хочешь, чтобы его могли изменить извне.

Уверен? Ведь там нельзя по-другому, если не извращаться. Как минимим, нужно или заствлять клиента явно удалять копии, или использовать обертки, которые не предоставляют удобного доступа к объекту.

Добавлено 27.01.11, 20:20

Цитата korvin @ 27.01.11, 20:17

Цитата D_KEY @ 27.01.11, 20:08

Так покажи, как это на Delphi. Из обсуждения я понял, что это не так просто, если Point - класс.

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

1) вернуть копию;
2) изменить интерфейс TRect;
3) сделать класс TPoint иммутабельным.

1) кто удалит копию? если обертка, то какой интерфейс она предоставляет клиенту и что ему придется об этом знать?
Пойдут ли на это программисты?
2) каким образом?
3) тогда потеряем возможность модифицировать его внутри TRect.