[ООП ГМ]Почему 1.+(2) а не +(1, 2)

Очевидно же! С точки зрения ООП ты шлешь сообщение «+» объекту X с параметром Y. И ессно это штука не коммутативна.

Нотацию +(1,2) поддерживают языки с ООП на generic functions, типа CLOS. Но и там о коммутативности можно забыть.

С точки зрения ООП ты шлешь сообщение «+» объекту X с параметром Y.

С точки зрения рационального дизайна зачем привязывать эту операцию к объекту определенного типа? Или это последствия элегантного дизайна ООП?

т.е. предлагаете класс (или интерфейс) «+», а «+(a, b)» просто создание нового экземпляра с использованием конструктора (кстати какого? и как добавлять новые конструкторы в класс «+»)?

>Или это последствия элегантного дизайна ООП?

Ты меня удивляешь! Вообще-то это тяжелое наследие Симулы. Я думал, это очевидно.

Чтобы сделать как ты хочешь нужна поддержка абстрактных типов данных. А в таком случае ООП как бы и не нужен.

Это можно организовать с помощью typeclass'ов или принудительной реализации спец. интерфейса (типа Numeric). И тогда класс «+» будет совершенно тривиальной штукой, сделанной на основе генериков.

И по иедее, в современных ООП системах каких-то технических препятствий нет.

А как ты будешь знать, по какому правилу складывать объекты без этого?

bitches don't know 'bout my CLOS

я намекаю что тупое следование правилам ООП не всегда полезно

так жо как и раньше, только при появлении коммутативности не придется писать

// Дубли
Number{
  String +(String s)
}

String{
  String +(Number n)
}

// 
+(String s, Number n)

Дорогой, нет, ну правда, хватит с нас лиспу)

> Но и там о коммутативности можно забыть.

это почему?

Ну в принципе да, дублирование.

А на примере generic functions кто-нить может дать пример? А то я в этом ООП фигово шарю.

Че там примеры давать. Там все элементарно - методы не привязаны к классам, соответственно, с классами онанировать не надо.

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

generic functions - это из лиспа ;)

Да знаю, чё) Вот только работать с ними почти не приходилось. Я на лиспе почти не пишу.

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

>это почему?

А с чего ты взял что объекты «2» и «3» должны одинаково реагировать на сообщение «+»? Важным свойсвтом объекта является состояние. Т.е. сообщене «+» по определению не будет «чистым», а значит и о коммутативности мы можем говорить только в частном случае.

В чистой ООП системе все является объектом. А поведение не определяется формально.

> А с чего ты взял что объекты «2» и «3» должны одинаково реагировать на сообщение «+»?

Ну потому что сигнатура и сама функция такая. И например (defmethod add ((a integer) (b integer)) (+ a b)) будет коммутативным методом, который единожды определяется для соответствующих классов, в отличие от классического ооп.

Важным свойсвтом объекта является состояние.

Кто сказал, что состояние объекта меняется при вызове метода? Оно же может и не меняться.

Коммутативность метода несложно получить, если ее хочется.

>+(1, 2)

Ты опечатался. Единственно правильно: (+ 1 2)

>Кто сказал, что состояние объекта меняется при вызове метода? Оно же может и не меняться.

Получить можно. Но это не значит что метод будет коммутативен в общем случае и ты не сможешь «выстрелить себе в ногу». Это же касается и CLOS.

А вот допустим в хаскеле... Хотя и там можно заюзать unsafePerformIO

Ну потому что сигнатура и сама функция такая

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

А в динамических языках гарантии вообще нет никакой. Ничто не мешает в любой объект (вольно или не вольно) инжектировать все что угодно.

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

Объект инкапсулирует состояние, у операции состояний нет.

Ну я же написал что инкапсулирует, хорошо «на исконном» - прячет, реализацию. И чтобы еще точнее, не обьект, а класс. Вот ты можешь спрятать реализацию за интерфейсом и пользоваться интерфейсом вне зависимости от реализации.

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

И да, перегрузка операторов - зло в чистом виде, его надо запретить раз и навсегда. Пользующихся - расстрелять.

> «a»+3

Чего-чего? Если рассматривать ЭТО как конкатенацию, то всё становится на свои места =)

> перегрузка операторов - зло в чистом виде

Ну не скажи. Тот же operator* (или как он там выглядит для $your_favorite_language) вполне логично перегрузить для тех же матриц

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

Не может, операция сложения не должна менять состояние операндов.

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

То что один и тотже код копируется по 2 раза это нормально? И операция сложения не должна соответствовать никакой логике работы, не неси чушь. Ни конкатенция строк, ни массивов, ни сложение чисел и неупорядоченных коллекций не зависит от их логики работы. Типичный пример с коллекциями - объединяем элементы, если обе упорядочены то некоммутативно, если хотябы одна неупорядоченна то коммутативно. И неважно List это Queue или Set. При реализации вне интерфеса тебе потребуется всего два метода. Если же следовать твоей логике то на _любую_ реализацию интерфейса Collection потребуется писать как минимум парочку операций сложения (или юзать наследование, что приведет к еще большему гимору, или юзанию костылей типа примесей).

ps. названия интерфейсов из жабки

ага, а как расматривать 3.+(«a») ? Или ты будешь писать реализацию сложения числа и всех возможных типов в классе числа? Я знал что идеи ООП несколько маразматичны, но не до такойже степени.

>Или ты будешь писать реализацию сложения числа и всех возможных типов

Визитор как-бы решает

в классе числа?

А, ну да, ещё во всеми обожаемых плюсах операторы можно объявлять вне классов

И да, белочка, что за баттхерт? Можно же определить оператор+(Тип1, Тип2) с реализацией сложения, а оператор+(Тип2, Тип1) выразить через первый

Визитор как-бы решает

Завязывай с травой, визитор для других целей.

А, ну да, ещё во всех нормальных языках функции можно объявлять вне классов

фикс

и все в Number? 8)

>визитор для других целей

Ну почему же, та же множественная диспетчеризация по сути. Только вот в языках со статической компиляцией можно перегружать операторы as is, компилятор сам всё разрулит; в Smalltalk-е с его динамической типизацией сложение реализовано через самый что ни на есть визитор

Number - это нечто абстрактное, визитором же можно распределить диспетчеризацию по его сабклассам (SmallInteger, Large{Positive,Negative}Integer, Fraction, Float), как это сделано в одном языке

Потому что + не всегда коммутативен. Банальный пример - конкатенация строк.

Конкатенация строк через плюсик - это мерзость, на самом деле =)

Касательно синтаксиса же - в сипэпэ можно писать и так и так. Но всё равно надо реализовать правый и левый.

Не я смолтолк не ковырял, но прозреваю что посещение одного объекта называется иным образом 8)

не в синтаксисе дело а в интерпитации.

Вообще в «говноцэпэпэ» и так принято писать код в одном методе - оператор+=(), а бинарные операции - односрочные. их можно вообще макросом генерировать)

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

А в классе числа - от числа. И что делат ьбедному компилятору?

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

Пожалуйста, ради всего святого, не делай так никогда. explicit не зря придумали :)

Не, ну вообще очевиднее написать string(3)+«a», хоть это и на несколько байт длиннее. Тогда и експлисит можно.

Всё зависит от того, хотим ли мы «1»+1==«11» или же 2. А вообще неочевидные перегрузки не нужны.

Это безопаснее!

експлисит можно

Нужно! Для каждого конструктора от одного аргумента - в обязательном порядке (исключение - конструктор копирования, но порой и его есть смысл за'explicit'ь)

хотим ли мы «1»+1==«11» или же 2

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

А вообще неочевидные перегрузки не нужны.

Потому и спрашивается сфигали не вынестиреализацию из объектов.

Так кто тебе мешает вынести?

ты

очевидный фикс: искать метод +() сначала у левого операнда, если его нет, брать из правого

PS завязывай с шишками.

Ведь операция сложения определена на множестве объектов и интуитивно обладает коммутативностью.

Белка, попробуй на досуге сложить 2 матрицы :)

> Ведь операция сложения определена на множестве объектов и интуитивно обладает коммутативностью.

Как уже писали, можно определить операцию +(Type1, Type2), а +(Type2, Type1) выразить через первую. Это если таки нужна коммутативность. Одна строчка кода не страшна. Зато есть возможность (по дефолту) таки делать операцию некоммутативной.

А вот операцию * стоит считать коммутативной? Для чисел она коммутативна, а для матриц - нет.