Вопрос про метаобъектный протокол.

anonimous, это опять ты?

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

«Вот тебе void*. Это метаобъект. Что он делает и как им пользоваться сам догадывайся»?

Кастаните кто-нибудь арчимага с лавсаном.

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

Ну, например суперклассы, в широком смысле. И зачем нужен отдельный протокол для суперклассов, если вполне подходит тот, который используется для классов, или для объектов?

Вот тебе void*. Это метаобъект. Что он делает и как им пользоваться сам догадывайся»?

Ну, допустим void — это экземпляр Object и от него наследует какой-нибудь theVoid, и что? делай с ним то же самое, что с любым другим объектом или классом, меняй поля, создавай экземпляры etc и что? Зачем протокол то отдельный?

Угадал автора по заголовку.

Я, кажется, понял, что ты не понял сути слова «протокол». Это не какая-то отдельная хрень, а просто интерфейс метаобъектов. Описание того, какие поля есть у Object, какие из них можно менять, и к чему приводят подобные изменения. В языке или есть доступ к Object и какой-то протокол работы с ним, или доступа нет и объектная система — это чёрный ящик.

собственно, в Ъ ООП протокол един для всего — сообщения.

в Ъ ООП протокол един для всего — сообщения.

Ты тупое днище, не путай протокол с транспортом.

а просто интерфейс метаобъектов

Ну, если для метаобъектов нужен *отдельный* интерфейс, то почему он не нужен для мета-метаобъектов? мета-мета-метаобъектов?

А что есть метаобъект без метаобъектного протокола? Какое сообщение ему послать чтобы он создал мне другой объект с нужными свойствами? Как узнать кто его суперкласс? Как он будет диспатчить сообщение по дереву наследования в конце концов?

Ну, если для метаобъектов нужен *отдельный* интерфейс, то почему он не нужен для мета-метаобъектов?

Потому что

Rule 10. The metaclass of Metaclass is an instance of Metaclass

А что есть метаобъект без метаобъектного протокола?

объект в некоторой иерархии связей

Какое сообщение ему послать чтобы он создал мне другой объект с нужными свойствами?

Такое же, какое любому другому, например create, зависит от языка ес-но.

Как узнать кто его суперкласс?

так же как у любого объекта, с помощю сообщений, например object.parent.parent

Как он будет диспатчить сообщение по дереву наследования в конце концов?

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

Он не отдельный. Он такой же по виду, как у других объектов. В это-то и вся суть метаобъектов же.

Просто в языке или есть Object.class, [Object class], или как вы называете его в своей семье; или метаобъектов совсем нет (и интерфейса к ним, естественно, тоже). Наличие мета-мета-мета-объектов и/или их отличие от уже определённых — это тоже часть протокола.

Rule 10. The metaclass of Metaclass is an instance of Metaclass

не понял, какое это имеет отношение к делу.

например create, зависит от языка ес-но.

Так это как раз и есть протокол, язык то тут не при чем. Язык определяет как ты напишешь - Obj.create / Obj create / (create Obj) / Obj::create / etc. А то что сообщение create делает то-то и то-то определяет метаобъектный протокол.

Если метаобъектов нет, то и разговора нет. Но, вот, например, в том же Io, можно строить произвольные иерархии метаобъектов. Но там нет никакого отдельного протокола. Во всяком случае, никто это слово там вслух не произносит:) Протокол един — сообщения.

вообще то диспетчирезация — это не дело объектов, а дело реализации

Ну вот опять дважды два. Как раз зависит как она реализована, если она реализована через этот же метаобъектный протокол - ты имеешь возможность ею управлять, как в CLOS, или не управлять, как в Java.

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

Это как телевизор смотреть вверх ногами и с выключенным звуком - такая мера на ЛОРе: разрешается создавать тему readonly. Читать можно, писать нельзя - посты медитативные. Воодушевляет!

Тебе нужна реализация X <> Y - дык рекурсия же. Тебе непонятно, кому-то понятно и у него есть «метапротокол». Чем не такой-же тупняк?

Может стоит посмотреть в сторону сериализации?

Часть смысловой нагрузки слова «протокол» — это ещё следствие того, что интерфейс класса в CL образуют обобщённые функции (generic). Там интерфейс класса называют протоколом, потому что по одному только определению класса нельзя понять, какие функции имеют методы для этого класса. Поэтому протокол: «Вот определение класса Foo. А ещё я даю честно слово, что у функции equal где-то будет реализован метод для этого класса» вместо «Foo реализует интерфейс Comparable, где есть метод equal».

The metaclass of Metaclass is an instance of Metaclass

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

А ведь любую структуру можно описать через объекты, например: var object(for method in ...) = objectIdentity. Кстати, тут же видно, что иммутабельность сосёт, поскольку тогда нельзя написать for. Поэтому ФП невозможно, и о чём все эти споры — не понятно.

Примерно так же нетрудно нарисовать окружность.

сука, до лиспа добрался.

Потому что нужно читать лавсана и чтить как отца и мать свою!

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

в том же Io, можно строить произвольные иерархии метаобъектов

В нём вообще нет метаобъектов. Есть прототипы.

Если бы в нём были метаобъекты, то не составило бы труда переопределить чтение поля. Например, чтобы «Dog color := red» создавало файл «Dog/color» и записывало туда «red», а «Dog color» производило чтение этого файла.

То есть в Ио нет свойств?

Допустим, есть язык X и Y и в обоих есть метаобъекты. Но в X есть метаобъектный протокол, а в Y нет. Что будет такого, что можно сделать в X, но нельзя в Y

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

А в X можно сделать всё, что прописано в протоколе. Как правило там прописывается рефлексия (можно получить для заданного класса список полей, методов; вызвать по имени метод). В CLOS и Python прописывается как читать/писать поля, как вызывать методы. То есть можно, например, сделать «объект» FS, через который читать файлы как FS.etc.passwd.

в Ио нет свойств

Можно эмулировать

> obj m set 3
> obj m get
=> 3

Постеснялся бы, что ли ). Речь про «сахар» шла, хотя бы, фиг с ним, с протоколом.

Если бы в нём были метаобъекты, то не составило бы труда переопределить чтение поля.

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

o := Object clone
o setSlot("newSetSlot", getSlot("setSlot"))
o setSlot("setSlot", method("oh, shit" print))

o newSetSlot("foo", 1)
o bar := 2
o foo print

//oh, shit1

В нём вообще нет метаобъектов

судя вот по этому вот странноватому правилу

The metaclass of Metaclass is an instance of Metaclass

это как раз таки в clos метаобъекты какие то странные

Спасибо за ссылку, но это уже смотрел. Это первым в гугле по сабжевому запросу вылезает. Но, глядя на ту ахинеею, которую тут плел в свое время автор этой статьи, доверия эта информация не вызывает. К тому же, он не показал там ничего особенного, при этом наговняв простыню в 10 экранов. Как-то не убедительно:)

Как правило там прописывается рефлексия (можно получить для заданного класса список полей, методов; вызвать по имени метод)

Это называется интроспекция, а не рефлексия, в Ъ-языках это искаропки.

То есть можно, например, сделать «объект» FS, через который читать файлы как FS.etc.passwd.

Это можно сделать в Io безо всякого протокола, и даже без метаобъектов

непонятно, причем тут вообще метаобъекты

Если SetSlot можно переопределять, значит метаобъектный протокол всё-таки есть. Только в случае Io он применяется к самому объекту.

В варианте с метаобъектами было бы что-то вроде:

o := Object clone
o meta setSlot("newSetSlot", getSlot("setSlot"))
o meta setSlot("setSlot", method("oh, shit" print))

o2 := Object clone
o2 meta := o meta

судя вот по этому вот странноватому правилу

The metaclass of Metaclass is an instance of Metaclass

Это правило из Ъ-ООП Smalltalk

значит метаобъектный протокол всё-таки есть

Даже не знаю... Выглядит как простое переопределение слотов. setSlot — это тоже слот. хз.

Это называется интроспекция, а не рефлексия, в Ъ-языках это искаропки.

Вопрос API. Для ООП разумно к классу привязать объект с соответствующими методами

Я, что то в смоллтоке в последнее время стал все больше и больше разочаровываться:) Вот сегодня узнал еще до кучи, что там нельзя иметь более одного суперкласса. А так — множественного наследования там нет, гомоиконности — нет, классы как лишняя сущность, опять же... Теперь вот еще это правило странное(хотя, возможно, я просто не понял). хотя, конечно, динамика, экстремально позднее связывание, концепция «все есть объект» — это все конечно остается. Хороший ЯП, но прототипные пошли дальше и стоят выше по эволюционной лестнице ООП.

Для ООП разумно к классу привязать объект с соответствующими методами

В прототипных яп класс вообще ничем не отличается от объекта.

Даже не знаю... Выглядит как простое переопределение слотов

В ООП есть базовый интерфейс: создание объекта, чтение/запись слота, вызов метода. Для Io — clone, setSlot, getSlot, активация слота. Если что-то из этого можно переопределять, то это и есть метаобъектный протокол.

лавсан адекват

Может и адекват, но глуповатый. Где то видел тред, где он с пеной у рта доказывал, что в лиспе все есть объект, как в смоллтоке например. Да и так, фанатизмом от него за версту несет. в меру адекватный, да.

Где то видел тред, где он с пеной у рта доказывал, что в лиспе все есть объект, как в смоллтоке например.

А это неверно?

* (class-of 1)

#<BUILT-IN-CLASS COMMON-LISP:FIXNUM>

defmethod на fixnum тоже можно добавить.

можешь сделать что-то в таком вот роде

one = instance of 1
one.foo = "bar"

one + 1 --> 2
one.foo --> bar
1.foo --> undefined

То что ты показал, это ровным счетом то же самое что в JS. Там Number, String, Boolean, null, undefined — примитивные типы, которые могут себя вести, отчасти как объекты, в том смысле, что они наследуют от своих классов.

Точней, пардон, null и undefined сюда не входят, это де факто чистые примитивы. Хотя раньше был тип Undefined, емнип, его убрали.

//fixed

Да нет же, в JS number/string/boolean — примитивные типы (никаким местом не объекты), а Number/String/Boolean — их boxed-версия. null и undefined вообще boxed-версии не имеют.

Некоторые операции просто автобоксят примитивы.

Вполне понятно, почему так сделано: производительность. Но в некоторых языках честные объекты, а не боксинг.

без протокола ты круг не нарисуешь.

Ну, я примерно это и сказал. Объекты в том смысле, что к ним, таки, можно отсылать сообщения, все таки, и они наследуют. Их условно можно назвать иммутабельными объектами. Насчет null и undefined, да это я запарился:) я пофиксил ниже:)

Они не объекты и офигенно отличаются по поведению от объектов.

В JS 7 (6 не считая Symbol) типов, объекты — один из них. Не всё является объектом.

Пруф того, что примитивы ни разу не похожи на свои же объектные версии:

var a = new Boolean( false );

if (!a) {
    console.log( "Oops" ); // never runs
}

В языках, где всё есть объект, такого тупо не может быть.

Вполне понятно

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