Что такое ООП

Потому что в ООП метод определяется первым аргументом. А в примере g (x, y) зависит от типа y.

ну так чо тебе мешает этот y ставить первым в своем выражении? Было g(x, y) стало y g(x). Разница тут ровно такая же как между инфиксной и префиксной записью.

Точно так же ООП выражается в функциональном виде, если передать объект дополнительным аргументом.

Потому что в ООП метод определяется первым аргументом.

CLOS, обобщенные функции же, ты чего.

если передать объект

вот именно, что объект. Синтаксис тут второстепнен, он не имеет значения. Однако, если ты имеешь дело с объектами — значит у тебя ООП, независимо от расстановки скобок. Вызов функции в глобальном пространстве имен — это сообщение отправленное глобальному объекту, при этом отправителем может быть он сам.

А что ты думаешь о неделе высокой моды, прошедшей в Лондоне в сентябре? Кстати какой там синоним к слову «лопать» и perjuicio это по-испански «предрассудок». Подумай об этом.

Хотел уже начать спорить, посмотрел определение в вики:

Объе́кт в программировании — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств (атрибутов) и операций над ними (методов)

Так то да, и 5 это объект, и фукнция `+' это объект.

ну так чо тебе мешает этот y ставить первым в своем выражении? Было g(x, y) стало y g(x).

Ладно, а что делать для такого случая?

class C a where
  h :: [a] -> Int

instance C Int where
  h = length

instance C Double where
  h x = length x + 1

-- Tests
> h [1, 2, 3]
3
> h [1.0, 2.0, 3.0]
4
> h (tail [1])
0
> h (tail [1.0])
1

То есть для списка целых — одна функция, для списка вещественных — другая.

Кто-то запрещает возвращать из метода новый объект, не трогая старый?

Мне проще на других типах показать, думаю, суть от этого не изменится

List do(
  length := getSlot("size")
)


NumberList := List clone do(
   push := method(x, if(x type == "Number", resend))
)
StringList := List clone do(
   push := method(x, if(x type == "Sequence", resend))
   length := method(resend - 1)
)

stringList := StringList clone
numberList := NumberList clone

stringList push(1) 
stringList push("foo")
stringList push("bar")

numberList push("foo")
numberList push(1)
numberList push(2)


numberList println // list(1, 2)
stringList println // list(foo, bar)

numberList length println // 2
stringList length println // 1

Ну и какие свойства и методы для этих свойств у плюса?

Кто-то запрещает возвращать из метода новый объект, не трогая старый

Если метод уже что-то возвращает, то некуда новый объект возвращать. Ну и стилю мышления ООП как-то плохо соответствует: newPoint = point move x y, newDisplay = display draw newPoint — так, что ли? А что должно произойти при newDisplay = display draw point1; newDisplay2 = display draw point1 ? На дисплее должна быть только вторая точка?

Привет. На лиспер не заходишь? Поможешь с вопросом по cl-gobject-introspection?

то некуда новый объект возвращать.

Что значит некуда?

Вообще, когда говорят «возвращает», обычно имеется в виду — ложит на стек, не?

Оппа, мамкин программист пожаловал. «Свойства для свойств» — это сильно, канешн.

Мне проще на других типах показать, думаю, суть от этого не изменится

Только чтобы с твоими numberList, stringList необходимо использовать именно твои конструкторы. Предположим, была функция getCoords display, возвращающая list(x,y) с целыми координатами.

В Хаскеле автоматически результат получает возможность применения операции h. То есть можно делать h(getCoords display).

У тебя придётся либо переписывать функцию getCoords, либо для добавления метода использовать явную конвертацию : display getCoords toNumberList h

А потом модель дисплея изменилась и координаты стали вещественные. В Хаскеле опять всё автоматически применится, а у тебя придётся всюду изменять getCoords toNumberList на getCoords toDoubleList

Я спросил исключительно по приведённой формулировке. А ты пока подумай ещё раз насчёт посещения психиатра.

Ага, если бы ты еще понял эту формулировку, было бы ваще хорошо.

Функция «+» — это не символ «+». Символ это одно, а то куда он указывает(будучи ссылкой) — это другое. Так вот, речь идет не о сиволе «+», который есть имя сообщения, и может указывать, к слову, на что угодно, хоть на функцию «devide», а именно о том объекте, куда он указывает, в данном случае — функции.

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

Оппа, мамкин программист пожаловал

оппа, с каких пор маня-говнокодеры против мамкиных программистов?

Вообще, когда говорят «возвращает», обычно имеется в виду — ложит на стек, не

Это в Forth. А в ООП нет понятия «стек». Есть только объекты и их сообщения. И глобального объекта «стек» в ООП без мутабельных объектов тоже быть не может.

Хз, можно ли в ООП, по крайней мере в синхронном коде забыть о стеке. К примеру, есть разница между fu = function(){return 1}иfu = function(){myStack.push(1)}, никуда от этого не денешься. Стек омжно в ООП рассматривать как дефолтный объект для хранения промежуточных результатов, так правильнее будет. Совсем абстрагироваться от него мы не можем.

без мутабельных объектов тоже быть не может.

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

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

newPoint = point move x y, newDisplay = display draw newPoint — так, что ли? А что должно произойти при newDisplay = display draw point1; newDisplay2 = display draw point1 ? На дисплее должна быть только вторая точка?

firstPoint = new Point(10, 20)
secondPoint = new Point(30, 40)

firstPoint.display
secondPoint.display

В Хаскеле автоматически результат получает возможность применения операции h. То есть можно делать h(getCoords display).

можно сделать так, что getCoords будет возвращать тот или иной тип в зависимости от вызывающего кода. Но проще просто использовать полиморфизм — различные реализации h для разных типов

coords1 = getCoords // returned instance of DoubleList
coords2 = getCoords // returned instance of NumberList

coords1 h
coords2 h

Там выше по треду утверждалось, что объект это

сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств (атрибутов) и операций над ними (методов)

И было сообщено, что «+» (математическая функция) - это объект.

В следующий раз урок чтения будет платным.

И что, это противоречит как-то тому что я сказал?

Object-oriented design is the roman numerals of computing.

И ты это высказыване своим постом ещё раз подтвердил. ¯\_(ツ)_/¯

Или ты отвечаешь, какие методы и свойства есть у плюса, или валишь нахрен.

что «+» (математическая функция)

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

Да любые методы и свойства, как и у любого другого объекта.

Какое состояние у «объекта» + ?

+1 послал сообщение 5, теперь 5 — это 6. Я правильно понял ход твоих мыслей? ;)

Нет, зачем. 5 +(1) — ты тут посылаешь объекту 5 сообщение +(1) и возвращаешь объект 6. Посылка сообщения не означает обязательно мутацию реципиента.

Но объект — это ведь что-то имеющее состояние. Какое состояние у объекта 5 и как он может его поменять?

Какое состояние у «объекта» +

то в котором он пребывает по-дефолту. Ты его можешь изменить. Состояние объекта — это поведение объекта, которое можно изменить, в ФП, by contrast, состояние менять нельзя, поэтому *считается*, что его нет.

Кроме того, при вызове, он проходит ряд состояний — подстановка, редукция, возврат значения.

Блин, это же элементарно

5 do(
  setSlot("+", getSlot("-"))
)

writeln(5 +(1)) // 4

как он может его поменять?

В быдло-ООП не может.

Изменение состояния означает изменение поведения. Так, в примере выше, объект 5 стал отвечать на сообщение + иным образом. Хотя в Ъ понятие «изменение состояния» — это хреновое описания происходящего. Уместнее говоить об изменении поведения. К примеру, акторы вообще не имеют четко определенного состояния. Но так уж сложилось, говорим не птичьем языке, поэтому пусть будет состояние.

Честно признаться я не понимаю, что ты пытаешься доказать. ;)

Есть фунции — они детерминированные. (Например Date() и Rnd() функциями не являются, т.к. возвращают каждый раз другое значение.)

Есть объекты — нечто с внутренним состоянием. (Структуры, классы, процессы в erlang.)

И есть методы/сообщения — нечто меняющее (или не меняющее) у объекта его внутренне состояние.

Так о чём мы сейчас говорим?

что ты пытаешься доказать

Я ничего не пытался доказать, просто отвечал на вопросы

(Например Date() и Rnd() функциями не являются, т.к. возвращают каждый раз другое значение.)

Они являются функциями, просто с точки зрения ФП они не чистые. Но тут все сводится к терминологии — функция как подпрограмма, функция как отображение, функция как объект — это все разные понятия. ИМХО, в программировании математических функций вообще не может быть, это просто член в голове. Функция может описывать программу, но не реализовывать ее.

И есть методы/сообщения — нечто меняющее у объекта его внутренне состояние.

Не обязательно.

нечто меняющее (или не меняющее) у объекта его внутренне состояние.

В смысле, менять сообщение ничего не обязано, хотя в ответ на сообщение объект может изменить свое состояние, если захочет.

Так о чём мы сейчас говорим?

О том, видимо, что все что ты перечислил — это все объекты(или акторы), включая сообщения.

это все объекты

«Если у тебя в руках молоток, то всё кажется гвоздем» ;)

В 90% случаем что-то одно можно выразить через что-то другое. С потерей или выиграшем — вопрос другой. Считай, что это изоморфизмы.

Но в общем случае, на ООП свет клином не сошёлся.

Секта Свидетелей ООП. Разумеется, тут же повылазили лисперы с CLOS :-).

firstPoint.display
secondPoint.display

И куда эти точки должны выводится? Предположим, что изначально у нас Display — мог быть файл или экран.

coords1 = getCoords // returned instance of DoubleList
coords2 = getCoords // returned instance of NumberList

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

То есть раньше у тебя была системная библиотека с кодом

Display := Object clone do(
   ...
   getCoords := method(list(Display height, Display width))
)

Теперь ты добавил h для NumberList. Идёшь в системную библиотеку и исправляешь на

Display := Object clone do(
   ...
   getCoords := method(NumberList(Display height, Display width))
)

Потом библиотека обновляется и heigth и width становятся вещественными

Снова лезешь в код:

Display := Object clone do(
   ...
   getCoords := method(DoubleList(Display height, Display width))
)

А можно и наподобие твоего синтаксиса сделать, так, чтобы h обрабатывала входные данные в зависимосити о их типа.

Вот это можно продемонстрировать?

И куда эти точки должны выводится?

Да куда угодно, метод display, конечно вызывает где то мутации, но мы бы могли бы написать и так

new Point(10, 20).display
new Point(30, 40).display

придётся переписывать всё, что потенциально может вернуть этот тип.

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

Вот это можно продемонстрировать?

Ну я имел в виду просто ветвления, в зависимомти от типа аргумента

h := method(x,
  if((x type) == "Foo", doSmth...; return)
  if((x type) == "Bar", doSmthElse...; return)
)

Ну я имел в виду просто ветвления, в зависимомти от типа аргумента

Так можно и ООП считать разновидностью процедурного программирования. Ведь любой метод можно реализовать ветвлением.

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

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

Поменял, как ты считаешь?

Конечно, нет. Ты просто обозвал функцию вычитания символом «+».