Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kouzdra ([info]kouzdra) в [info]programming
@ 2005-11-18 12:35:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Реализация вызова метода в O'Caml
На самом деле идея простая, но красивая.

В чем пробелма: с точки зрения статического контроля типов, объект может выступать
под любым типом, которому соотвествует его сигнатура (то есть - наличествуют
заданные методы и их типы подходят). В месте, где происходит вызов метода,
компилятор ничего не знает про тип самого объекта. Он обычно не знает, что такой тип
вообще существует.

В месте, где создается объект, компилятор как правило ничего не знает о том, что
где-то этот объект будет использоваться с конкретной сигнатурой. В отличие от
языков, где иерархия основана на наследовании все предки в месте создания объекта
известны, O'Caml базируется на отношинее subtyping'a.

Понятно, что можно в объекте держать таблицу методов с именами и динамически искать их.
Но это как-то не очень. Цикл устраивать. Потому делается так (решение подходит и к реализации
записей с subtyping'ом по включению набора полей):

Все имена методов нумеруются глобально по всей программе. Это может делать линкер, в
O'Caml это делается динамически при запуске программы. Далее в качестве VMT можно использовать
таблицу длины n_meth, где n_meth - количество имен методов. В пустующие клетки не записывается
ничего, в остальные - адреса функций.

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

Идея хороша всем, кроме того, что n_meth может быть довольно большим (напирмер 1000), а заводить для каждого класса
(пусть 200 классов) табличку в 1000 слов несколько накладно - даже тут уже получится мегабайт. Это при
весьма умеренных n_meth и числе классов. Опять же - понятно, что таблики будут почти пустые.

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

Далее - в начало таблицы записывается подобранное p, а адреса методов располагаются в позиция по модулю
p. Вызов метода соотвественное делается просто - берется остаток от деления номера метода на p из таблицы
и вызывается то, что лежит по адресу.

Придумал это Didier Rémy в 1992 года:


Efficient Representation of Extensible Records. In Proceedings of the 1992 workshop on ML and its Applications, page 12, San Francisco, USA, June 1992


(Читать комментарии) - (Добавить комментарий)


[info]kouzdra
2005-11-18 13:21 (ссылка)
Все равно остается проблема, как из нее выбрать метод, не зная структуры объекта.
В Haskell ее просто каждый раз при передаче в другой контекст собирают заново (динамически).
Это можно, но существенно менее эффективно и кучу жрет:

допусти у нас есть x: < a: int, b: int, c:int > и соотвественон - табличка с тремя методами.
Мы должны его передать туда, где требуется
[Error: Irreparable invalid markup ('<a:int,>') in entry. Owner must fix manually. Raw contents below.]

Все равно остается проблема, как из нее выбрать метод, не зная структуры объекта.
В Haskell ее просто каждый раз при передаче в другой контекст собирают заново (динамически).
Это можно, но существенно менее эффективно и кучу жрет:

допусти у нас есть x: < a: int, b: int, c:int > и соотвественон - табличка с тремя методами.
Мы должны его передать туда, где требуется <a:int, b: int>, то есть - надо создать новую
табличку на два метода, перекопировать туда все и передать ее вместе с объектом.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]potan
2005-11-18 14:34 (ссылка)
Да, действительно, преобразование типов делается сложнее...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2005-11-18 14:51 (ссылка)
Возможно есть и более серьезные (неразрешимые) проблемы связанные с полиморфизмом -
например - как реализовать функцию

let apply f x = f x

Если в реальном вызове - x - объект, а f - хочет объект. Но apply-то про это
ничего не знает.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]potan
2005-11-18 15:29 (ссылка)
Haskell такое ест.
Хотя у него классы "более статические".

Похоже все это актуально и для решетчатого наследовния. Интересно, дойдут у меня когда-нибудь руки его реализовать...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2005-11-18 15:34 (ссылка)
У него нет subtyping'a. Так что боюсь, что это не переносится.

(Ответить) (Уровень выше)


(Читать комментарии) -