Привет!
Скажу еще о виртуализации методов и объектов :)
On 8/6/08, Andrey Cherezov <
[hidden email]> wrote:
> с "виртуальными" словарями путь более прямой, естественный и прозрачный:
> выделяется набор слов, через которые идёт всё откладывание кода, и этот
> набор реализуется собственным способом для каждого типа словарей.
Список слов, как объект, имеет два метода: добавить отношение и
разрешить имя (удалять отношения не принято), скажем:
RELATE-WORDLIST ( x addr u wid -- )
FIND-WORDLIST ( addr u wid -- x true | addr u false )
(опционально еще CAR и CDR для перечисления)
Эти методы могут быть как угодно виртуализованы, работая по своему для
различных wid (этот wid явно передается параметром), но их набор и
сигнатура должны быть те же. Примерно так же, как методы READ-FILE и
WRITE-FILE работают для файлов и для пайпов.
Допустим, выделен лексикон слов для откладывания кода, данных,
формирования потока исполнения и законченных определений,
представляемых в виде xt. Это немалый набор, который использует
область кода, область данных, управляющий стек, и подразумевает
внутреннее состояние и сохранение баланса (треть форт-системы ;).
Таким образом, за этим набором слов стоит некоторый объект, и эти
слова — методы к нему. Назовем этот объект кодогенератором. Заметьте,
объект "кодогенератор" является окружающим и не требует идентификатора
при обращении к нему. Это удобно, когда методов много, а
объектов-экземпляров мало (один).
Как быть, если иногда требуется работать с двумя или тремя объектами
"кодогенератор"? (реальный пример такой ситуации — сборка целевой
системы с иным форматом кода, чем инструментальная система). Поступить
так же, как для списка слов, передавать объект параметром — слишком
неудобно.
Вариант: ввести уровень косвенности в виде указателя на текущий
кодогенератор, и сделать обертки ко всем словам лексикона, чтобы они
вызывали методы текущего объекта (т.е., делали диспетчеризацию).
Далее, Андрей предлагает текущий кодогенератор связать с текущим
списком слов (тот, в который добавляются имена новых слов), например,
добавив в структуру wid ссылку на кодогенератор. Тогда, смена текущего
списка слов может повлечь смену кодогенератора. Это все будет работать
с одним системным кодогенератором, и крайне редко, для решения
специфичной задачи, в систему будет загружаться и другой
кодогенератор.
Другой вариант: игра начинается только тогда, когда понадобился этот
самый второй кодогенератор. Мы просто загружаем его лексикон в
отдельный обычный список слов. Далее, весь код, которому нужен этот
другой кодогенератор, мы статически к нему и привязываем. Все.
Код, который должен не зависеть от конкретного кодогенератора и
работать с каждым, загружается для каждого из этих дву-трех
кодогенераторов, привязываясь статически. Да, получается накладной
расход в памяти (будет несколько похожих экземляров объектного кода,
вместо одного экземпляра), но главное, что не будет накладных расходов
в исходном коде, и реализация каждого из кодогенераторов может без
модификаций использоваться как единственная в системе. В качестве
бонуса — оно будет работать быстрей, т.к. нет уровня косвенности в
виде "указателя на текущий объект".
--
Ruvim
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
