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

Цитата D_KEY @ 07.02.13, 07:52

Там проблема не в const, а в ссылочной семантике

Можно подумать в Java передаваемый в метод объект не может быть модифицирован внутри

Цитата --Ins-- @ 07.02.13, 09:55

Цитата D_KEY @ 07.02.13, 07:52

Там проблема не в const, а в ссылочной семантике

Можно подумать в Java передаваемый в метод объект не может быть модифицирован внутри

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

Цитата jack128 @ 07.02.13, 09:06

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

А с другой стороны, можно бы просто в среде var_параметры подсвечивать другим цветом или курсивом

Цитата --Ins-- @ 07.02.13, 09:57

А с другой стороны, можно бы просто в среде var_параметры подсвечивать другим цветом или курсивом

Можно их просто не использовать в неочевидных случаях

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

Можно их просто не использовать в неочевидных случаях

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

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

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

Можно их просто не использовать в неочевидных случаях

Они и так используются только тогда, когда нужно, так просто параметр как var никто не объявляет

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

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

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

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

Не к делфи, а к языкам с параллельным существованием двух семантик - ссылочной и значений, которые определяются неявным образом и зависят от "вида" типа(класс/структура/встроенный тип и пр.)

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

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

Один и тот же

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

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

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

Ч.и т.д.

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

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

Что значит "не нужен"? Он либо есть, либо его нет, это свойство кода. Ты же не используешь никакого спецификатора polymorphic.

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

Ничего ты не ограничишь. const или не const - это не твое дело, это декларация наличия/отсутствия логического изменения состояния.

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

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

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

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

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

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

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

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

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

Вот не ожидал от korvin'а такого непонимания контрактов...

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

korvin, вот тебе кусочек нашего вектора:

// не меняем передаваемый нам объект(т.к. копируем его), меняем свое состояние
void push_back (const value_type& val);
// удаляем у себя объект с конца, меняем свое состояние
void pop_back();
// возвращаем неизменяемую ссылку на наш последний элемент
// (позволительно и для константного объекта, т.к. клиент не изменит наши данные)
const_reference back() const;
// возвращаем изменяемую ссылку на наш последний элемент,
// (возможно только для неконстантного объекта)
reference back();

Может так будет понятнее...

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

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

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

Вот не ожидал от korvin'а такого непонимания контрактов...

При чем тут контракты? Контракт моего класса -- это интерфейс. Всё. Его поведение -- это внутреннее дело класса.

korvin, всё же на тебе джава плохо сказывается Как ты говоришь

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

Ч.и т.д.

А если хочется контрактов, пишите на Agda там, или Coq.

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

При чем тут контракты? Контракт моего класса -- это интерфейс. Всё. Его поведение -- это внутреннее дело класса.

Контракты здесь при том, что ты ради

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

возможности по модификации реализаций этих методов

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

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

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

А если хочется контрактов, пишите на Agda там, или Coq

Кроме контрактов ещё много чего хочется... Где есть всё?

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

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

А как насчет неочевидности из вызывающего кода, меняется параметр или нет? Видишь, в Java при отсутствии out-параметров проблемы все те же самые, только этим еще и пользоваться нормально невозможно без извратов

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

korvin, всё же на тебе джава плохо сказывается Как ты говоришь

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

Ч.и т.д.

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

Напишешь такой контракт?

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

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

Напишешь такой контракт?

Вообще в теории - да, напишу. Но долго буду писать. И в C++ его использовать будет неудобно.
Только вот одно "но": const на это всё и не претендует.

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

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

Нет, не изменяю. Это мой класс. Откуда ты знаешь, что они всегда будут неконстантными, может мне пока и не нужно изменять состояние объекта этими методами, а в будущем понадобится? Что делать потомкам, которые хотят что-то изменять этими методами? Я сознательно делаю "контракт" таким более общим, чтобы уменьшить связность.

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

Кроме контрактов ещё много чего хочется... Где есть всё?

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

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

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

Вообще в теории - да, напишу. Но долго буду писать. И в C++ его использовать будет неудобно.
Только вот одно "но": const на это всё и не претендует.

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

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