Сергей-4030: Все сообщения за 9 Декабря 2007 года

Mishka> Это наследие С++

Я бы сказал, наоборот. Методу equals нужна гибкость. Если бы == проверяло равенство "содержимого", то его нельзя было бы override средствами языка без костылей. В отличие от.

•  45
•  инфо
•  инструменты
• Ответить на сообщение

KILLO> lg 1953S контрастность 5000:1 в Москве 233$

Спасибо, сегодня заказал такой. Будем смотреть, когда придет.

•  инфо
•  инструменты
• Ответить на сообщение

Mishka>>> Это наследие С++
Сергей-4030>> Я бы сказал, наоборот. Методу equals нужна гибкость. Если бы == проверяло равенство "содержимого", то его нельзя было бы override средствами языка без костылей. В отличие от.
Murkt> Да, почему они не сделали перегрузку операторов? Побоялись, что толпа леммингов не осилит? Классная ведь штука.

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

PS Даже для тех, кто почитает других леммингами.

•  9
•  инфо
•  инструменты
• Ответить на сообщение

Сергей-4030>> Те места, где ее можно применять "правильно" - раз-два и обчелся. Не стоит городить огород.
Murkt> Только используются эти места очень часто. Хотя бы те же "нестандартные" Numeric-типы (или они называются Number? не помню точно), типа BigInteger. Или StringBuffer/StringBuilder. В том же Питоне, в котором использование всех доступных возможностей "сделать красиво" (syntax hacking) считается тру и pythonic, перегрузка операторов используется только там, где она действительно имеет смысл. В стандартной библиотеке, в сторонних, вообще в любом коде, который я встречал - не видел ни разу чтоб перегрузка операторов использовалась в местах, в которых она выглядит неуместно.

А какие вы считаете уместными, кроме "стандартных" над всякими обертками "первичных" типов?

•  7
•  инфо
•  инструменты
• Ответить на сообщение

Murkt> Ну вот я указал некоторые. BigInteger - это ведь не обёртка над стандартным типом. Decimal - то же самое (не уверен, как он в джаве называется). Могу вот ещё нелогичность указать - "первичного" типа string нет, но конкатенация String'а в Джаве работает, а конкатенация чего угодно другого не работает. А ведь было бы удобно использовать + для создания StringBuffer/StringBuilder. Списки те же - тоже конкатенция. А плюс не работает. Матрицы складывать, вычитать, умножать (я имею в виду математические матрицы, то есть специально созданные для этого классы). В тех же множествах - and, or, xor. В питоне есть ещё хороший оператор in.

Я не настаиваю на абсолютной истине моего восприятия, но по-моему, почти все ваши примеры ложатся на "оберточный" образец. Кроме матриц. Но! Матрицы - довольно особый случай. Они не характерны для большинства приложений. И "стандартные" операции так-таки не очень хорошо ложатся для матриц. Если a и b - матрицы, то что такое a+b, a*b? Это зависит от реализации. Выгода здесь будет только если разработчик цельный день этими матрицами занимается и у него уже в памяти выжжены каленым железом "правильные" смыслы для этих операций. А если кто-то другой придет со стороны, или просто из другой части проекта, или сам человек написал два года назад и забыл? Вот так и рождаются кошмары. И это еще при более-менее разумном применении переопределения операторов. А уж когда начинаются всякие кошмары типа

Person p; Account accs[];

accs

+=time("Feb/1/00")-time("Jan/1/00");

имея в виду - записать человеку рабочее время за месяц - вот тут туши свет. А бывает и хуже.

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

•  5
•  инфо
•  инструменты
• Ответить на сообщение

Murkt> Отличался бы он чем-то от "безоператорного" варианта? Отнюдь, в безоператорном варианте было бы точно то же самое. Только писать нужно было бы больше.

Отличается безусловно. Тем, что определения операторов однозначны. Такой вариант:

Person person;
Account acc = Accounts.locate(person);
TimeCards tc = calculateWorkTime(new date("01/01/00"),new date("02/01/00"));
acc.credit(calculatePay(tc));

отличается НЕ только тем, что "писать нужно больше". Вернее, формально - да, только этим. А вот практически - этот код понятен любому разработчику, даже если он не знает ничего про то, как считаются рабочие дни, как производится оплата и т.п. Он более-менее самодокументирован. А вот пример с "операторным подходом" этого преимущества совершенно лишен. Что на практике приведет элементарно к большему количеству ошибок и НАМНОГО более затратной поддержке такого кода.

•  3
•  инфо
•  инструменты
• Ответить на сообщение

Balancer> Вопроса не понял Если про возможность вызова class_name::class_name(..) - то нафиг ненужны. Если про доступ к конструктору извне класса вообще - то как же без него?

Именно про доступ извне класса. Т.е. нужны ли конструкции такого вида?

Some thing = new Some(parameters);

ЗЫ Имеется в виду - вне класса, конечно. Методы класса, разумеется, должны иметь доступ к конструктору.

•  инфо
•  инструменты
• Ответить на сообщение

Murkt> А вот такой вариант - да, отличается не только тем что нужно писать больше.

Так это типично. То есть, в конечном итоге, да, есть определенное количество классов, для которых удобно сделать перезагрузку операторов. И объектов этих классов (BigInteger и т.п) в программе может быть много. Но тем не менее вводить только для этих случаев механизм, который потенциально опасен во всех других случаях - не выглядит на 100% здравой идеей. Никто, разумеется, не сможет строго доказать, что так лучше. Как и, скажем, goto. Но согласитесь, что на ваши доводы "за" так-таки существуют вполне весомые доводы "против". Истина в данном случае исключительно в практике.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

>>Т.е. нужны ли конструкции такого вида?
>>Some thing = new Some(parameters);
Balancer> А что в качестве альтернативы?

В качестве альтернативы - фабрики объектов. Плюс подхода - контроль создания нового объекта.

Something creature = Forest.createGreyWolf();

•  7
•  инфо
•  инструменты
• Ответить на сообщение