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

Цитата korvin @ 07.02.13, 10:25

Это мой класс. Откуда ты знаешь, что они всегда будут неконстантными

Из предметной области, вестимо.

Цитата korvin @ 07.02.13, 10:25

Что делать потомкам, которые хотят что-то изменять этими методами?

Изучать предметную область.

Цитата korvin @ 07.02.13, 10:25

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

fixed

Цитата korvin @ 07.02.13, 10:25

Посмотри подпись у D_KEY'а еще раз =)

А ты мою

Цитата korvin @ 07.02.13, 10:25

Ну так полумеры не нужны

Озвучь свой опыт использования C++, чтобы говорить мне что там нужно, а что - нет.

Добавлено 07.02.13, 10:31

Цитата korvin @ 07.02.13, 10:25

В общем мое мнение такое: const в данном случае никакой пользы не приносит, а только увеличивает связность системы, делая клиентский код более зависимым от реализаций объектов.

Кэп нам сообщает, что зависимость от любого интерфейса увеличивает связность - лучше не зависеть ни от чего. А const на это никак не влияет.

Сообщение отредактировано: MyNameIsIgor - 07.02.13, 10:31

Цитата korvin @ 07.02.13, 10:10

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

Надо довести эту позицию до логического завершения и передавать все параметры в виде одного нетипизированного указателя. А то ведь поразвелось тут фанатиков типизации! А вдруг тебе понадобится добавить или удалить параметр?

Цитата MyNameIsIgor @ 07.02.13, 10:30

Озвучь свой опыт использования C++, чтобы говорить мне что там нужно, а что - нет.

Разве я говорю тебе, что тебе нужно/ненужно в C++? Вроде все началось с того, что D_KEY сказал, будто этот const нужен вообще везде. =)

Добавлено 07.02.13, 10:45

Цитата MyNameIsIgor @ 07.02.13, 10:30

Цитата korvin @ 07.02.13, 10:25

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

fixed

Какие же неудобства? То что им не придется перелопачивать код, т.к. они понадеялись на const? Думаю, это терпимое неудобство. =)

Цитата korvin @ 07.02.13, 10:43

Разве я говорю тебе, что тебе нужно/ненужно в C++? Вроде все началось с того, что D_KEY сказал, будто этот const нужен вообще везде. =)

Ну, я тебя понял в ключе именно C++, ибо ты на его примерах пытаешься обосновать ненужность const.
Ну, хорошо, пусть разговор про "везде". Тогда да, контракты как в Agda безусловно лучше. Но разговор о том, что в Delphi, C#, Java и вообще имя им легион нет даже такого, "плюсового" const.

Цитата MyNameIsIgor @ 07.02.13, 10:30

А ты мою

Наверное именно поэтому D_KEY'евский push_back копирует объект, не зависимо от того, хочет этого клиент или нет? =)

Добавлено 07.02.13, 10:58

Цитата MyNameIsIgor @ 07.02.13, 10:47

Ну, я тебя понял в ключе именно C++, ибо ты на его примерах пытаешься обосновать ненужность const.

Ну так в C++ есть const, потому и примеры на нем.

Цитата MyNameIsIgor @ 07.02.13, 10:47

Ну, хорошо, пусть разговор про "везде". Тогда да, контракты как в Agda безусловно лучше. Но разговор о том, что в Delphi, C#, Java и вообще имя им легион нет даже такого, "плюсового" const.

Дык потому что он там не нужен, надежней вручную скопировать объект или написать класс, который будет сам копировать объекты, типа

class CopyingContainer<A> extends NonCopyingContainer<A> {
 
    public add(A a) {
        super.add(a.copy());
    }
 
    public A get(int index) {
        return super.get(index).copy();
    }
}

и никаких ограничений на реализацию интерфейса => меньшая связность.

Цитата korvin @ 07.02.13, 10:53

Наверное именно поэтому D_KEY'евский push_back копирует объект, не зависимо от того, хочет этого клиент или нет? =)

Нет, push_back копирует элемент потому, что C++ основан на семантике значений. Если клиент не хочет копировать, он может сделать вектор указателей.

Добавлено 07.02.13, 11:02

Цитата korvin @ 07.02.13, 10:53

Дык потому что он там не нужен, надежней вручную скопировать объект или написать класс, который будет сам копировать объекты, типа

А при чём тут копирование то? Я не втыкаю...

Цитата MyNameIsIgor @ 07.02.13, 10:59

А при чём тут копирование то? Я не втыкаю...

При том, что это позволит не изменить исходный объект и при этом свободно работать со всеми методами его копии, а не только теми, которые обозначены как const.

Цитата korvin @ 07.02.13, 11:09

При том, что это позволит не изменить исходный объект и при этом свободно работать со всеми методами его копии, а не только теми, которые обозначены как const.

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

Добавлено 07.02.13, 11:34
D_KEY, чего молчишь? Трави давай.

Цитата korvin @ 07.02.13, 10:10

В чем большая понятность? Вы еще к имени каждой функции обяжите приписывать префикс function_, капитаны =)

При чем тут капитанство?

Цитата

От каких ошибок избавляет? Пример пожалуйста.

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

Цитата

Это наличие двух семантик никак не влияет на семантику кода, т.к. изменяемые объекты всегда ссылочны.

Эм. int в ява ссылочный?

Цитата

Впрочем какая разница, если можно передать структуру-значение, содержащую указатель? Так что "две параллельные семантики" - это миф. =)

Это суровая реальность При чем тут структуры какие-то? Да, если нужно, ты можешь добиться ссылочной семантики.

Цитата

Цитата D_KEY @ 07.02.13, 09:40

Ничего не понял.

Ч.и т.д.

Я не понял, что ты хотел сказать этим?

Цитата

Он либо есть, либо его нет, это свойство кода.

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

Цитата

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

Какие ограничения?

Цитата

В том, что вначале ввели const-методы, а потом "средства для обхода".

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

Цитата

Какое нафиг логическое состояние применительно к приватным данным? Все логическое состояние объекта -- это его интерфейс. Что там внутри никак к этому не относится.

А при чем тут приватные данные? Это контракт метода.

Цитата

Цитата D_KEY @ 07.02.13, 09:40

Если это действительно нужно, то:

Так это ж не то же самое -- можно передать NULL, не?

Ну во всяких явах ты тоже можешь его передать Проверяй на NULL, если нужно.

Добавлено 07.02.13, 12:01

Цитата korvin @ 07.02.13, 10:13

Пусть клиентский код сам решает, копировать объект или передать ссылку.

В С/С++ действует семантика значений, поэтому копирование(а так же "перенос" в новом стандарте С++) - естественное поведение. Если не хочешь копирования - используй типы для косвенного обращения - указатели, ссылки, "умные" указатели и т.д.

Добавлено 07.02.13, 12:04

Цитата korvin @ 07.02.13, 10:21

напиши класс вектора, как D_KEY привел выше, в контракте которого (т.е. на этапе компиляции, как в случае с const) гарантируется, что pop_back() и back() не будут вызваны у пустого вектора, что вызов pop_back() точно удалит последний элемент и размер вектора уменьшится на единицу и при этом pop_back() не тронет (логически) остальные элементы, что push_back() добавит именно переданный элемент именно в конец и не тронет (опять же логически) остальные элементы, при этом размер вектора увеличится на единицу.

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

Добавлено 07.02.13, 12:06

Цитата korvin @ 07.02.13, 10:25

Откуда ты знаешь, что они всегда будут неконстантными, может мне пока и не нужно изменять состояние объекта этими методами, а в будущем понадобится?

Пример можешь привести?

Цитата

чтобы уменьшить связность.

Связность от const никак не изменяется.

Добавлено 07.02.13, 12:07

Цитата korvin @ 07.02.13, 11:09

При том, что это позволит не изменить исходный объект и при этом свободно работать со всеми методами его копии, а не только теми, которые обозначены как const.

Так ты работать будешь с копией, а не с объектом. Я же могу спокойно "читать" публичное логическое состояние объекта и работать с ним.

Добавлено 07.02.13, 12:10

Цитата MyNameIsIgor @ 07.02.13, 11:18

я объявлял интерфейс для константных методов, и где не предполагалось изменение объекта, использовался именно он.

Вот. Об этом я и говорил, что это могут быть совершенно лишние сущности и полиморфизм на ровном месте.

Сообщение отредактировано: D_KEY - 07.02.13, 12:29

Цитата D_KEY @ 07.02.13, 11:59

Вот. Об этом я и говорил, что это могут быть совершенно лишние сущности и полиморфизм на ровном месте.

Ну, а иначе там никак - приходится мириться с отсутствием const. В конце концов я смирился

Цитата D_KEY @ 07.02.13, 11:59

Эм. int в ява ссылочный?

А что, int в яве изменяемый?

Цитата D_KEY @ 07.02.13, 11:59

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

Я не использую полиморфизм. Он просто есть.

Цитата D_KEY @ 07.02.13, 11:59

Какие ограничения?

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

Цитата D_KEY @ 07.02.13, 11:59

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

Нет, есть плюсовики, которые делают из мухи слона и заморачиваются на каких-то мелочах =)

Цитата D_KEY @ 07.02.13, 11:59

А при чем тут приватные данные? Это контракт метода.

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

Цитата D_KEY @ 07.02.13, 11:59

Проверяй на NULL, если нужно.

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

Цитата D_KEY @ 07.02.13, 11:59

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

Что значит "не практично"? Вполне практично, это контракт вектора, любое другое поведение -- нарушение контракта и уже не вектор.
Ну вот на практике и const не особо-то и нужен. =)

Цитата D_KEY @ 07.02.13, 11:59

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

Проблемы низкоуровневых языков. Их и не надо все вписывать, они почти все выводятся автоматически. =)

Цитата D_KEY @ 07.02.13, 11:59

Пример можешь привести?

Попозже.

Цитата D_KEY @ 07.02.13, 11:59

Связность от const никак не изменяется.

Изменяется.

Цитата D_KEY @ 07.02.13, 11:59

Так ты работать будешь с копией, а не с объектом. Я же могу спокойно "читать" публичное логическое состояние объекта и работать с ним.

Ну меня-то не напрягает отсутствие const-методов и я спокойно читаю свойства оригинального объекта. =)

Цитата D_KEY @ 07.02.13, 11:59

Вот. Об этом я и говорил, что это могут быть совершенно лишние сущности и полиморфизм на ровном месте.

Не знаю как в C#, но в яве есть например instanceof, который нафиг рушит все эти "скрывающие" интерфейсы. Если конечно ты догадываешься какие там могут быть классы у объекта. =)

Добавлено 07.02.13, 13:23

Цитата D_KEY @ 07.02.13, 11:59

полиморфизм на ровном месте.

Это надо записать. =)

Цитата korvin @ 07.02.13, 13:19

Цитата D_KEY @ 07.02.13, 11:59

Эм. int в ява ссылочный?

А что, int в яве изменяемый?

Да, там изменяемые примитивные типы.

Цитата

Я не использую полиморфизм. Он просто есть.

Зачем он есть, если ты его не используешь? Где есть? Моя твоя не понимать.

Цитата

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

Не понял. Если тебе надо изменять какие-то поля из константных методов - делай эти поля mutable.

Цитата

Нет, есть плюсовики, которые делают из мухи слона и заморачиваются на каких-то мелочах =)

Нет, это просто холиварный голод

Цитата

Что значит "не практично"? Вполне практично, это контракт вектора, любое другое поведение -- нарушение контракта и уже не вектор.

"Не практично" означает, что описание контрактов для статической проверки занимает больше кода, чем код реализации

Цитата

Ну вот на практике и const не особо-то и нужен. =)

Классический blub paradox

Цитата

Проблемы низкоуровневых языков. Их и не надо все вписывать, они почти все выводятся автоматически. =)

Где?

Цитата

Изменяется.

Какие ваши доказательства?

Цитата

Ну меня-то не напрягает отсутствие const-методов и я спокойно читаю свойства оригинального объекта. =)

Но ты можешь втуда нагадить, а я - нет

Цитата

Не знаю как в C#, но в яве есть например instanceof, который нафиг рушит все эти "скрывающие" интерфейсы

У языка программирования не должно быть задачи мешать программисту писать говнокод(по причине ее неразрешимости).

Сообщение отредактировано: D_KEY - 07.02.13, 13:30

Цитата D_KEY @ 07.02.13, 13:29

Да, там изменяемые примитивные типы.

Пример изменения int можно?

Добавлено 07.02.13, 13:35

Цитата D_KEY @ 07.02.13, 13:29

Не понял. Если тебе надо изменять какие-то поля из константных методов - делай эти поля mutable.

А может мне просто убрать два ключевых слова -- const и mutable и не захламлять код? А то скоро как в джаве "public static final" будет =)

Цитата D_KEY @ 07.02.13, 13:29

Но ты можешь втуда нагадить, а я - нет

Т.е. я объявляю, что не буду изменять логическое состояние объекта:

void foo(const MyClass &a)
{
    // ...
}

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

Цитата D_KEY @ 07.02.13, 13:29

"Не практично" означает, что описание контрактов для статической проверки занимает больше кода, чем код реализации

Проблемы низкоуровневых язычков =) А на самом деле три строчки кода в сумме с описанием типа данных =)