«Я жалею, что придумал термин «объекты» много лет назад,
потому что он заставляет людей концентрироваться на мелких идеях.
По-настоящему большая идея — это сообщения».
Здравствуйте, vaa, Вы писали:
vaa>Вот он говорит: vaa>
vaa>«Я жалею, что придумал термин «объекты» много лет назад,
vaa>потому что он заставляет людей концентрироваться на мелких идеях.
vaa>По-настоящему большая идея — это сообщения».
vaa>Разве объект не может быть сообщением?
может. твой пойнт по сути о — базовую абстракцию (объект) использовать для создания другой — сообщения.
его пойнт — о самой абстракции (сообщении).
Здравствуйте, vaa, Вы писали:
vaa>Вот он говорит: vaa>
vaa>«Я жалею, что придумал термин «объекты» много лет назад,
vaa>потому что он заставляет людей концентрироваться на мелких идеях.
vaa>По-настоящему большая идея — это сообщения».
vaa>Разве объект не может быть сообщением?
В мире Кея — нет. Кей представлял себе объекты как "отдельные компьютеры". То есть приложение в его модели — это сеть "компьютеров", каждый из которых — чёрный ящик со своим состоянием.
Обмениваются они сообщениями. У сообщения в такой метафоре собственного поведения быть не может.
vaa>
vaa>set x = CreateObject("сообщение")
vaa>call послать x
vaa>
Обратите внимание на то, что кеевским сообщениям в современной ОО-нотации соответствуют методы.
То есть в вашей записи сообщением является "послать", а x — это дополнительный параметр этого сообщения.
Выходит, в современной нотации ваш вопрос можно переформулировать как "разве объект не может быть методом?"
И получается так, что — нет, не может. Поверх ООП можно построить какую-нибудь систему RTTI или рефлексии, где могут быть объекты-дескрипторы элементов системы типов, в том числе и методов.
Но дескриптор метода — не то же самое, что и метод.
vaa>Почему нельзя просто применить к данным функцию? vaa>
vaa>let r = hash "some data"
vaa>
Потому, что в мире кеевского ООП, нет никаких "данных" и никаких "функций". Это — осознанный выбора, следствие одного из основных дизайн-решений. Кей это решение называл homoiconicity — то есть использование ровно одной метафоры вообще для всего.
В его мире, к примеру, нет "скаляров" или "плоских данных". Чтобы прибавить к двойке пятёрку нужно отправить объекту "2" сообщение "прибавить" с аргументом "5", где "5" — это ссылка на объект-пятёрку.
В ответ на это сообщение двойка пришлёт ссылку на другой объект типа "число". И значением этого числа будет "7".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Обратите внимание на то, что кеевским сообщениям в современной ОО-нотации соответствуют методы.
Поскольку Smalltalk полностью динамический, то Кей решил назвать "сообщением" — вызов метода, которого у объекта может не быть. Вроде как один объект посылает сообщение другому объекту, а тот уже сам определяет, что с этим делать, при этом в случае отсутствии метода/сообщения также возвращалось специализированное "сообщение":
В Smalltalk-80, если ни один метод не соответствует сообщению, объект по умолчанию возвращает сообщение doesNotUnderstand. Вызывающий объект может отреагировать на него, либо передать сообщение дальше, либо сигнализировать об ошибке. Класс также может переопределить действие по умолчанию и сделать что-то, кроме возврата doesNotUnderstand.
Здравствуйте, Sinclair, Вы писали:
S>В мире Кея — нет. Кей представлял себе объекты как "отдельные компьютеры". То есть приложение в его модели — это сеть "компьютеров", каждый из которых — чёрный ящик со своим состоянием.
Не обязательно.
Ящик может быть без состояния.
S>Обмениваются они сообщениями. У сообщения в такой метафоре собственного поведения быть не может.
Но сообщение может содержать ссылку на другие ящики.
Т.е. ящики могут обмениваться другими ящиками.
И если для ящика с состоянием принципиально, чтобы в сообщениях фигурировало лишь его ID, то объекты без состояний можно передавать по-значению, т.е. создавая копии их.
В этом моменте абтракция Кея недостаточно чётко отделяет мух от котлет.
Здравствуйте, Sinclair, Вы писали:
S>То есть в вашей записи сообщением является "послать", а x — это дополнительный параметр этого сообщения. S>Выходит, в современной нотации ваш вопрос можно переформулировать как "разве объект не может быть методом?"
S>>В мире Кея — нет. Кей представлял себе объекты как "отдельные компьютеры". То есть приложение в его модели — это сеть "компьютеров", каждый из которых — чёрный ящик со своим состоянием.
V>Не обязательно. V>Ящик может быть без состояния.
Здравствуйте, 4058, Вы писали:
4>Поскольку Smalltalk полностью динамический, то Кей решил назвать "сообщением" — вызов метода, которого у объекта может не быть.
Всё наоборот. Началось всё с сообщений, которые объект может обрабатывать по своему желанию.
И уже из этой идеи стала вытекать полная динамичность смолтока.
4>Вроде как один объект посылает сообщение другому объекту, а тот уже сам определяет, что с этим делать, при этом в случае отсутствии метода/сообщения также возвращалось специализированное "сообщение":
4>
4>В Smalltalk-80, если ни один метод не соответствует сообщению, объект по умолчанию возвращает сообщение doesNotUnderstand. Вызывающий объект может отреагировать на него, либо передать сообщение дальше, либо сигнализировать об ошибке. Класс также может переопределить действие по умолчанию и сделать что-то, кроме возврата doesNotUnderstand.
Совершенно верно. Поэтому, скажем, паттерн прокси/скелетон для удалённого исполнения в смолтоке не требует ни компилятора IDL, ни динамической генерации кода через рефлексию.
Плюс там по аналогии с лиспом, которым Кей открыто вдохновлялся при проектировании смолтока, код существует в виде данных.
Поэтому нет никакой проблемы, скажем, отправить блок кода на исполнение удалённому объекту — как это сделано в СУБД GemStone.
А также программным способом проинспектировать и поизменять программный код.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Простите, это вот что было? Это то, как вы понимаете идею смолтока, или то, что должно было быть вместо смолтока?
Потому что в смолтоке то, что вы пишете, записывается примерно так, и совершенно не выглядит дурацким:
Cезам откройся.
дверь1 откройся.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Не обязательно. V>Ящик может быть без состояния.
Это частный случай более общей модели, в котором состояние ящика является пустым. В мире Кея решение иметь или не иметь состояние полностью отдаётся на откуп ящику.
В частности, у чисел состояние есть, и оно неизменяемо. Но никаких средств выразить эту неизменяемость, как и само наличие либо отсутствие состояния, в Smalltalk нету.
S>>Обмениваются они сообщениями. У сообщения в такой метафоре собственного поведения быть не может. V>Но сообщение может содержать ссылку на другие ящики.
Это никак не противоречит тому, что я написал.
V>Т.е. ящики могут обмениваться другими ящиками.
Ссылками на другие ящики.
V>И если для ящика с состоянием принципиально, чтобы в сообщениях фигурировало лишь его ID, то объекты без состояний можно передавать по-значению, т.е. создавая копии их. V>В этом моменте абтракция Кея недостаточно чётко отделяет мух от котлет.
Да, конечно. Никто и не говорит, что абстракция Кея является непревосходимой вершиной архитектурной мысли.
Современные мультипарадигменные языки безусловно удобнее смолтока для решения прикладных задач.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Простите, это вот что было? Это то, как вы понимаете идею смолтока, или то, что должно было быть вместо смолтока? S>Потому что в смолтоке то, что вы пишете, записывается примерно так, и совершенно не выглядит дурацким: S>
S>Cезам откройся.
S>дверь1 откройся.
Бредом это становится, когда начинаешь сам декомпозировать и распределять роли. Тут серьёзный подвох в том, кто именно выполняет действие:
либо дверь открывается сама после подачи команды — смолтолк, либо кто-то дверь открывает.
В некоторых случаях идеи смолтолка работают:
task = computer.StartCompute(data)
, но в большинстве — нет, потому что тебе частенько нужно выполнить какой-то алгоритм над объектом. В таких случает объект является объектом, а не субъектом.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>, но в большинстве — нет, потому что тебе частенько нужно выполнить какой-то алгоритм над объектом. В таких случает объект является объектом, а не субъектом.
А, вы про это — ну да, Кей явно переоценил ООП.
Ну так это и было полсотни лет тому назад. Тогда редко какая программа на смолтоке занимала больше пары страниц.
Проблемы с выделением ролей и избыточными обязанностями начинаются при росте объёма решаемых задач.
Так-то анемик выглядит куда как более продуктивной моделью, чем рич; и особенно хорошо, когда анемик ещё и поддерживается инфраструктурой языка и среды исполнения.
Скажем, в смолтоке невыносимо легко заменить арифметику целых на арифметику каких-нибудь BigNumber. Но зато сделать в нём математику над традиционными int64 столь же эффективной, как и в С/С++ уже значительно сложнее.
В той же Java эффективность анемик резко падает при выходе "дата обжектов" за пределы примитивных типов.
Оттуда там любовь ко всяким "ооо, давайте мы представим набор комплексных чисел в виде двух массивов double" и прочему шаманству.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В той же Java эффективность анемик резко падает при выходе "дата обжектов" за пределы примитивных типов. S>Оттуда там любовь ко всяким "ооо, давайте мы представим набор комплексных чисел в виде двух массивов double" и прочему шаманству.
Не очень понял мысль. Проблема жавы в данном случае в отсутствии value object. Там любой объект это полноценная махина на хипе, с кучей доп расходов по памяти, с доп нагрузкой на GC. Поэтому вместо миллиона таких объектов выгодней создать два объекта-массива.
И эта проблема решается введением, собственно value object-ов, которые нам всё обещает оракл. Когда объект будет лежать на стеке или в плоском виде внутри массива, с нулём доп расходов, копироваться по значению и тд и тп. По большому счёту вопрос оптимизации.
К анемик вроде это никакого отношения не имеет. Анемик это по сути вопрос — где писать код методов. В самом объекте, или в другом месте. Разные уровни абстракции.
Здравствуйте, Baiker, Вы писали:
vaa>>Разве объект не может быть сообщением? B>Может! И сообщением. И телеграммой. И ботинком. СЕЙЧАС ты зачем нам это всё рассказываешь? Ты считаешь, тут никто не знает про Смоллток?
Я не знаю Смолтолка. Расскажите?
Вот какое отношение ООП Алана Кея имеет к вызову методов? И почему это вообще ООП, а не Событийно-ориентированное программирование (СОП)? Из постулата "Всё — объекты, и всё их взаимодействие — через посылку сообщений" для меня следует, что каждый объект может существовать в своей нитке — в своём потоке исполнения, а значит сразу отсутствуют последовательность выполнения. Никакой объект не знает состояния другого объекта, а значит нельзя полагаться на последовательность сообщений. Если взять пример приведённый выше:
Чтобы прибавить к двойке пятёрку нужно отправить объекту "2" сообщение "прибавить" с аргументом "5", где "5" — это ссылка на объект-пятёрку.
В ответ на это сообщение двойка пришлёт ссылку на другой объект типа "число". И значением этого числа будет "7".
то вот без дополнительных постулатов считать, что ответным сообщением будет 7 нельзя. Потому что перед сообщением "прибавить" с аргументом "5", к объекту "2" может прийти сообщение от другого объекта "прибавить" с аргументом, например, "1", поэтому ответом будет "8", а не "7".
Вот откуда взялось последовательность исполнения? Его нет в описании от Алана Кея...
Здравствуйте, vsb, Вы писали:
vsb>Не очень понял мысль. Проблема жавы в данном случае в отсутствии value object. Там любой объект это полноценная махина на хипе, с кучей доп расходов по памяти, с доп нагрузкой на GC. Поэтому вместо миллиона таких объектов выгодней создать два объекта-массива.
Совершенно верно.
vsb>И эта проблема решается введением, собственно value object-ов, которые нам всё обещает оракл. Когда объект будет лежать на стеке или в плоском виде внутри массива, с нулём доп расходов, копироваться по значению и тд и тп. По большому счёту вопрос оптимизации.
vsb>К анемик вроде это никакого отношения не имеет. Анемик это по сути вопрос — где писать код методов. В самом объекте, или в другом месте. Разные уровни абстракции.
Ну, если говорить строго — то да, анемик это про методы, а value-обжекты это про размещение данных.
Тем не менее, эти вопросы несколько коррелируют.
Смотрите: у Кея всё живёт в хипе, включая объекты-числа. Даже если мы их специальной магией интернируем, всё равно они ведут себя как забоксенные Integer и Double в Java.
Со всеми вытекающими последствиями.
Хотим посчитать сумму массива чисел — бежим по массиву ссылок, и отправляем каждую из ссылок в объект-аккумулятор при помощи метода .+().
Анемика предлагает убрать метод + из чисел, а вместо этого иметь некий stateless сервис-объект, у которого есть метод +(number1, number2).
C этой точки зрения value-типы представляют собой экстремальное развитие идей анемики — у них нет своей VMT и идентичности; они описываются только своим состоянием, а, значит, их можно безопасно копировать и перемешать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, B0FEE664, Вы писали:
BFE>..для меня следует, что каждый объект может существовать в своей нитке — в своём потоке исполнения, а значит сразу отсутствуют последовательность выполнения...
В частности об этом я говорил, утверждая, что тебе частенько нужно выполнить какой-то алгоритм над объектом, и что в таких случаях объект является объектом, а не субъектом.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, B0FEE664, Вы писали: BFE>то вот без дополнительных постулатов считать, что ответным сообщением будет 7 нельзя. Потому что перед сообщением "прибавить" с аргументом "5", к объекту "2" может прийти сообщение от другого объекта "прибавить" с аргументом, например, "1", поэтому ответом будет "8", а не "7".
Можно. Объект "2" — "вечен" и неизменен. Сколько бы раз мы ни прибавляли к двойке пятёрку, ответом всё равно будет ссылка на 7. Если кто-то прибавит к этой двойке 1, то этот кто-то получит в ответ ссылку на 3, что никак не помешает остальным прибавлять к двойке всё, что угодно.
BFE>Вот откуда взялось последовательность исполнения? Его нет в описании от Алана Кея...
АФАИР, Кей, в том числе, предполагал и возможность независимых потоков исполнения "внутри" объектов. Но я не слишком хорошо знаком с оригинальным смолтоком, чтобы осмысленно обсуждать вопросы многопточности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Философ, Вы писали:
BFE>>..для меня следует, что каждый объект может существовать в своей нитке — в своём потоке исполнения, а значит сразу отсутствуют последовательность выполнения... Ф>В частности об этом я говорил, утверждая, что тебе частенько нужно выполнить какой-то алгоритм над объектом, и что в таких случаях объект является объектом, а не субъектом.
Не обязательно. Сообщение может быть таким: примени к себе следующий код: "<некоторый код для исполнения>". Например, message: eval, data: "alert('Hello World');".
