Ruby: message passing

Это вобщем то не более чем, описание идеи.
Можно сказать я вызвал метод класса а под названием +.
А можно сказать я послал объекту а сообщение +.
Суть не особо меняется. Хотя в чем то нотация сообщений
понятнее.

А нет никакой разницы, хотя отправка сообщений могла бы быть асинхронной...

Разница в том, что при вызове функции заранее известен её адрес, а при посылке сообщения адрес вычисляется в рантайме и зависит от объекта (его типа, положения в иерархии наследования и т.п.). Но я думаю вы и так это знаете. А разница между "методом" и "сообщением" терминологическая в основном. Хотя есть нюансы, в том же C++ метод может означать очень разные вещи. Так что "сообщение" - более корректный термин при описании семантики Руби.

> при посылке сообщения адрес вычисляется в рантайме и зависит от объекта

В питоне как раз так, но называют методами. А в ObjC может вычисляться компилятором, но всё равно сообщением зовётся.

Это от того, что в ООП нет строго определенной терминологии. Каждый понимает и трактует как хочет.

> в чём разница между вызовом функций и посылом сообщений?

Если не углубляться в дебри, то посылка сообщения - это поиск функции в ассоциативном массиве и ее вызов. Т.е. никакой разницы :)

> посылка сообщения - это поиск функции

> Т.е. никакой разницы

Да уж, совсем никакой :)

А в чем профит собсно такой техники? Оно же тормозит. Haskell например умеет compile time определять адреса нужных функций. И работает он на два порядка быстрее.

> А в чем профит собсно такой техники? Оно же тормозит

Это холиворный вопрос %) Такая техника проста в реализации и вообще типична для динамически типизированных ОО-языков. То есть, вместо тго, чтобы писать сложный компилятор с нормальными проверками типов, все проверки сваливают на рантайм.

> Haskell например умеет compile time определять адреса нужных функций.

Во-первых, Хаскелл статически типизированный; во-вторых, вряд ли его compile-time способности относятся к ООП :)

run-time полиморфизм.

> run-time полиморфизм.

Его и Си++ умеет, без всякого поиска в таблицах :)

Его и Си++ умеет, без всякого поиска в таблицах :)

ЩИТО?

man позднее связывание!!1

При позднем связывании адреса определяются динамически во время выполнения программы, а не статически во время компиляции, как в традиционных компилируемых языках, в которых применяется раннее связывание. Сам процесс связывания заключается в замене виртуальных функций на адреса памяти.

>> Его и Си++ умеет, без всякого поиска в таблицах :)

> ЩИТО?

Читать учись, вот щито.

как по-твоему работают виртуальные функции в С++?

> как по-твоему работают виртуальные функции в С++?

из VTBL по индексу выбирается указатель, а что?

Virtual Method Table.
Table.

>Его и Си++ умеет, без всякого поиска в таблицах :)

фэйл. уйди.

>Короче, в чём разница между вызовом функций и посылом сообщений?

Поправьте если не прав, но посылка сообщений - это *одна из техник* вызова функций, более унифицированная и как правило использующая рефлексию языка для поиска нужных методов и объектов. В самом сообщении находится информация о маршруте ( имя/типа объекта и слота ) и параметры метода. Такая техника удобна в некоторых случаях, и позволяет, например, широковещательные сообщения. В том же руби:

ObjectSpace.each_object(Enumerable) { |i| puts i.length }

Код проходится по всем объектам из иерархии ( в данном случае, по всем объектом, включающим модуль Enumerable, то есть всем, по которым можно итерировать ) и выполняет блок.

> Virtual Method Table

> Table.

Ассоциативная? :D

>> Его и Си++ умеет, без всякого поиска в таблицах :)

> фэйл.

Утипути :) Фэйлом может закончиться поиск в ассоциативном массиве методов Руби (Питона, Смолтока, ...). А в VTBL даже и поиска нет - обращение по гарантированно существующему индексу.

> уйди.

Только после того, как ты уйдешь учиться читать :D

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

> Фэйлом может закончиться поиск в ассоциативном массиве методов Руби (Питона, Смолтока, ...).

вот тут, на самом деле, поржал. =) не потому что фигня (нет), а потому что написано смешно =)

> я как раз прочитал ровно то, что ты написал.

Так ты мне не ответил - является ли VTBL (или VMT, если хочешь) ассоциативным массивом? И может ли "поиск" метода в ней завершиться неудачно?

> ты писать научись, если хочешь, что бы тебя понимали

По-моему, меня только ты и не понял :)

> Так ты мне не ответил - является ли VTBL (или VMT, если хочешь) ассоциативным массивом? И может ли "поиск" метода в ней завершиться неудачно?

это уже дело десятое. таблица? таблица. а ты говорил, без таблиц =)

> ты говорил, без таблиц =)

Я говорил "без поиска в таблицах" :-P

> А в VTBL даже и поиска нет - обращение по гарантированно существующему индексу.

Ну концептуально большой разницы то нет. Решение что именно вызывать принимается в рантайме.

"вытаскивание" по индексу - частный случай поиска.

> "вытаскивание" по индексу - частный случай поиска.

При поиске есть хоть одно сравнение ключей. В случае VTBL его нет, поэтому вызов через VTBL по определению быстрее.

> вызов через VTBL по определению быстрее.

да кто ж спорит-то? =)

Да в общем-то никакой разницы. Простио посылая сообщение, ты можешь указать параметром имя метода, к примеру:

irb(main):001:0> 1.send gets.strip, 2
+
=> 3
irb(main):002:0> 1.send gets.strip, 2
-
=> -1