Что такое ООП

Чего? Ты жабакодер чтоли?

Объект отвеечает на сообщение иным образом, это и есть изменение поведения/состояния.

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

разуй глаза, то был ответ на вопрос о состоянии объекта 5

Свойства: количество, порядок и типы аргументов, тип возвращаемого результата, возможные рантаймовые исключения.

Методы: применить функцию к аргументам, частично применить к аргументам, проверить применима ли функция к данному количеству / типам аргументов.

Про плюс - моей пост выше.

Про 5 - это вырожденный объект, у которого состояние это его же значение и оно неизменяемо. Собственно в смолтолке так и есть.

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

Если мы говорим в терминах CS, то Date и Rnd это самые настоящие функции, но не чистые.

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

Именно, вот например у объекта `5' просто нет методов, меняющих его состояние. Если не брать в расчет приведенный выше пример с изменением самих методов, но тут вопрос, относить ли методы и объектную метаинформацию к состоянию? Но это в текущей дискуссии не важно совсем.

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

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

В обычном ООП типа плюсов, джавы, питона все именно так, и это действительно больно. Но в нормальном ООП можно переопределять методы не только в месте определения класса (даже в Go так сделали со структурками), а в качественном это можно делать даже в рантайме.

`5' просто нет методов, меняющих его состояние. Если не брать в расчет приведенный выше пример с изменением самих методов

Это про мой пример чтоли? Тот же setSlot — это метод меняющий состояние объекта типа «Number». Вообще, не знаю как в смолтоке, но в Io числа — полноценные объекты. От них даже наследовать можно

five := 5 clone do(
   foo := "bar"
)

writeln( five + 1 )  // 6 
writeln( five ?foo ) // bar
writeln( 5 ?foo )    // nil

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

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

числа — полноценные объекты. От них даже наследовать можно

Наследуются от классов, знаток ООП)

В прототипном ООП классы ничем не отличаются от объектов. От любого инстанса можно наследоваться.

В прототипном ООП классы ничем не отличаются от объектов

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

просто это ветвление абстрагировано от тебя в алгоритме диспатчинга сообщений

ИМХО в диспатчинге лукапы, а не ветвления. А процедурное программирование — это частный случай ООП, как и любое другое, а не наоборот.

Тот же setSlot — это метод меняющий состояние объекта типа «Number»

Вот тут спорно, в твоем IO просто объект является классом, а значит содержит в себе все методы, поэтому ты считаешь что меняется состояние объекта. В ООП где есть конечные объекты, которые не классы, вся эта инфа содержится в классе, а у объекта только стейт, и в этом случае твой setSlot не поменяет объект `5', а поменяет слоты в его классе.

в общем случае

В каком это общем? Класс-ориентированное ООП — это частный случай ООП, а не общий. А если говорить о более общем подходе, то прототипный подход тут как раз более общий, классовое ООП содержит ограничение, а подход с ограничениями не может претендовать на общность. К примеру, прототипное ООП с ограничениями на наследование от инстансов — это частный случай прототипного ООП, и как раз является классовым. Так что не надо тут про общесть.

а значит содержит в себе все методы

Нет не содержит, он их наследует. Хотя может и содержать, при желании. Но это все детали реализации, они нас волновать не должны.

Интересно, а я все представил наоборот, что прототипное ООП это как классовое ООП с отрезанным классо-объектным уровнем и оставленным метаобъектным уровнем, метаобъекты создают метаобъекты, наследуют друг друга и тд.

Но это все детали реализации, они нас волновать не должны.

Теюе уже говорили, что ты являешься ярким примером типичного говнокодера? Хоть книгу пиши на основе твоих мессаджей.

Но это все детали реализации, они нас волновать не должны

Именно, а по твоему коду выходит что идеологически он содержит методы, ведь у five появился метод foo, а у `5' нет.

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

Может ли классовое ООП быть прототипным? — Нет

Может ли прототипное ООП быть классовым? — Да. Для этого нужно просто ввести ограничения.

Может ли классовое ООП быть прототипным? — Нет

Потому что?

Какие именно методы? метод setSlot они оба нследуют делегированием от Object по дефолту. foo есть только у five, это его личное свойство, а 5 является родителем five.

Ну, как бы, в теории это возможно, наверное, если в качестве инстансов всегда использовать только сабклассы, но я не думаю, что это технически возможно в реальных ЯП. Поэтому, by design.

Если вызвать у five setSlot на setSlot - он ведь изменится только у five?

но я не думаю, что это технически возможно в реальных ЯП

http://habrahabr.ru/post/230619/ =)

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

Нет, это другое. Это реализация поверх реализации, можно и ноборот сделать, а говорим о дефолтных системах.

Если вызвать у five setSlot на setSlot - он ведь изменится только у five?

В смысле изменить метод setSlot у five? Да, тогда у five будет свой собственный setSlot. Это справедливо для любого объекта.

а говорим о дефолтных системах

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

Если уж ты заводишь речь об «что есть частный случай чего», то наименьший знаменатель для любого вычислителя — это Машина Тюринга.

А от всё остальное — это сахар и частный случай. Включая PP, OOP, FP ... и уйму других P.

Т.ч. твой любимый OOP — это частный случай BrainF*ck. ;) Deal with it.

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

А вообще, я думаю, такая «реализация» займет пару строк. Надо просто инициализировать кастрированные инстансы, с отрубленными методами clone, appendProto и prependProto.

ооп - это миф

Ок, не наследоваться и правда можно. Но есть еще изменение методов у класса, которое должно изменить поведение всех его объектов. В твоем IO это сработает?

somequest Презумпция невиновности, несмотря на его тупак, он не находится в списке persona non grata Pinkbyte ★★★★★ (27.11.2015 14:12:17) 09.12.2015 7:51:03

Расслабься :-).

это Машина Тюринга

Машина тьюринга — частный случай модели Акторов. Я как раз эту тему в соседнем треде про мультиметоды раскрыл, можешь почитать, если интересно.

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

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

(defgeneric foo)

(add-method
 foo
 (method ((x (and? integer? even?)))
	 (cl-format #t "foo on even int, (~a)~%" x)))

(add-method
 foo
 (method ((x (and? integer? odd?)))
	 (cl-format #t "foo on odd int, (~a)~%" x)))

(add-method
 foo
 (method ((x integer?))
          (y (lambda (y) (> y 0)))
	 (cl-format #t "~a~%" (+ x y))))

(foo 2) ;; печатает "foo on even int, (2)"
(foo 3) ;; печатает "foo on odd int, (2)"
(foo 1 2) ;; печатает "3"

Это тоже, что-ли, ООП?

В твоем IO это сработает?

Да, не вижу препятствий. Список родителей то у него останется.

моде́ль а́кторов представляет собой математическую модель параллельных вычислений

ref: https://ru.wikipedia.org/wiki/Модель_акторов

Машина тьюринга — частный случай модели Акторов. Я [..] эту тему [..] раскрыл

Что ты там раскрыл мне читать откровенно лень. Но и так ясно, что ты сравниваешь тёплое с мягким.

Любые тьюринг-полные вычислители - частные случаи друг друга :)

почему теплое с мягким? И то и другое — вычислительные матмодели, почему бы их не сравнить. И, собственно сравниваю даже не я, а Карл Хьюитт, который в одной из своих бумаг показал, что существуют алгоритмы нереализуемые в МТ, но реализуемые в Модели Акторов. То есть тезис Черча-Тьюринга опровергнут.

С точки зрения ООП, функция — это актор

Дальше не читал и не понимаю, почему вообще дочитал до этого момента

Скаежем так, МТ не является *актор-полной* моделью, поэтому является частным случаем, но не наооборот.

то можно рассмотреть GLS

А что это? Гуглится только гай стил.

Это тоже, что-ли, ООП?

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

Почему же? Под актором тут имеется ввиду объект. Во всяких рубях функции и методы являются вполне себе объектами.

Потому что утиная типизация (ага, оно выглядит как актор и, кажется, ведет себя как актор, значит оно — актор!) тут неуместна

Как это ты перепрыгнул от акторов к типизации. Ты же пробовал смолтолк? Объектной системе не нужна «типизация», когда надо ты просто спрашиваешь у объекта какого он типа.

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