LINUX.ORG.RU

Вопрос по реализации лукапа.

 ,


0

1

Пилю лукап для экспериментального прототипного языка.

Лукап планирую реализовать следующим образом. В каждом объекте есть массивы storage и protos и метод get, вида get(key). Если key не обнаруживается в storage, начинают перебираться все объекты ссылки на которые находятся в protos, у каждого объекта вызывается тот же самый метод get c запрошенным ключом, до тех пор, пока ключ не будет найден.

Возник вопрос. Что если в protos или в каком нибудь объекте из protos будет ссылка на тот же самый объект, из которого изначально вызывался get? Похоже на то, что будет зацикливание. Как лучше обработать данный случай? Просто пропускать такие объекты? Какие тут могут быть неожиданности?

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



Последнее исправление: aboutcard (всего исправлений: 3)

Какие тут могут быть неожиданности?

Цикл из более чем двух прототипов, лол. Ты анонiмус что ле?

A1
()

Лукап чего? Если динамических переменных, как-то не могу представить более одного прямого родительского контекста и зацикливания. В любом случае в лукап можешь передавать список уже обработанных объектов, чтобы предотвратить их повторную обработку.

staseg ★★★★★
()
Ответ на: комментарий от staseg

В любом случае в лукап можешь передавать список уже обработанных объектов, чтобы предотвратить их повторную обработку.

Спасибо. Думаю, это оптимальное решение.

aboutcard
() автор топика

О, привет, анонiмус!

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

Если точнее, у тебя получается «наследование» от наследника, и, если ты позволяешь такое, то в общем случае ничего сделать нельзя. Проброс «множества уже обработанных объектов», как это предлагает staseg, хоть и мог бы помочь, но выльется в огромные накладные расходы как по памяти (ведь нужно передавать такой список для _каждого_ сообщения), так и по производительности (ведь каждый обработчик сообщения должен будет проверить наличия текущего объекта в этом множестве, а это будет примерно O(m*n), где m — количество прототипов, n — глубина наследования, которая в случае прототипирования будет весьма большой). Более того, допустим у тебя объект B имеет прототипом объект A, который реализует метод get по-своему, но внутри вызывает метод прототипа, которым ты ставишь B, ну допустим (не знаком с синтакисом Io, но, думаю, ты поймёшь):

A get := method( 1 + proto get )
B := A clone
A proto := B
B get

Т.е. единственным прототипом A становится B, других прототипов нет. Поскольку объекты уникальны, изменив прототип A, ты повлияешь на всех наследников A, т.е. бывшие ранее валидные методы станут возвращать херню типа «Method not found», хотя фактически он есть. Ну, пример надуманный, но суть в том, что ты таким образом можешь поиметь такую кашу, что goto покажется детским лепетом.

korvin_ ★★★★★
()

Пилю лукап для экспериментального прототипного языка.

Ладно к делу. Круг на нем можно будет нарисовать?

anonymous
()

позволять объекту наследовать самому от себя. Пока склоняюсь к тому, что это нормально.

в теории во избежании NIL сущностей, объект может отнаследоваться by-self, но и то в практике реализации(и непосредственно сам от себя без посредников), а не в концепте языка.

MKuznetsov ★★★★★
()
Ответ на: комментарий от korvin_

По поводу производительности и памяти — это все верно, тут не поспоришь, но другого способа я не вижу. при правильном подходе к проектированию, слишком глубоких цепочек наследования в большинстве случаев можно избежать, кроме того, возможны другие оптимизации, поэтому, это все нивелируется на практике, при условии того, что разработчик понимает, что делает.

По поводу второго — нет никакой каши, все ясно. Предполагается, что человек, который это пишет, знает, что делает. Кто не понимает — пусть берут жабу и пишут. В крайнем случае, данный get можно оставить только на уровне реализации, но тогда это уже будет менее Ъ.

aboutcard
() автор топика
Ответ на: комментарий от aboutcard

По поводу второго — нет никакой каши, все ясно. Предполагается, что человек, который это пишет, знает, что делает. Кто не понимает — пусть берут жабу и пишут.

Ага, с прототипированием у тебя будут миллионы объектов с потенциальным количеством связей O(n^n), удачи разруливать.

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

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

aboutcard
() автор топика

Похоже на то, что будет зацикливание.

пробрасывай в каждый лукап адрес первого объекта, сравнивай.

vladimir-vg ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.