Хорошее MVC

[Psycho Tiger]

Для хранения общих свойств, типа названия предмета, ссылки на картинку и т. п. Т. е. если у тебя есть однотипные предметы в инвентаре, у них всех ссылка на один и тот же прототип.

А, для экономии памяти, понятно.

Реализовать промежуточный класс с ленивым геттером основной модели. Так называемый ассет основной модели. Всё, кто в неё попадает, может получить на неё ссылку.

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

[etc]

Сообщение от Psycho Tiger

А, для экономии памяти, понятно.

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

Сообщение от Psycho Tiger

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

Тем и плохо, что надо тянуть и не забыть.

Сообщение от dimarik

А я разве сказал, что this._user ассет самого себя? Он ассет кого надо ассет. Какого-то юзеря. Может текущего персонажа. Удобно с текущим пером меряться. Он под рукой всегда.

Димка, я чето не понимаю, на каком языке ты разговариваешь. Юзер — это пользователь. Всё, что к нему относится — его ассеты и ему на него ссылку и вообще находятся в нём. В том числе и персонажи. Но как может быть юзер ассетом персонажа, я не очень понимаю.

Сообщение от dimarik

Ну поменяется отображаемый контейнер, если ты сверху вниз на стадии смены контейнера пересеттишь этот ассет. Я не вижу смысла тут пользоваться прослушиванием ADDED/REMOVED

Речь шла о том, что отслеживать смену юзера самому ассету незачем, т. к. есть более важные события, которые следуют в результате смены юзера, например тот же ADDED/REMOVED. И если их слушают во вьювере, этого достаточно, чтобы обновить данные в соответствии с новыми условиями и юзером.

Сообщение от dimarik

Это по стандарту так?

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

[dimarik]

Сообщение от etc

Димка, я чето не понимаю, на каком языке ты разговариваешь. Юзер — это пользователь. Всё, что к нему относится — его ассеты и ему на него ссылку и вообще находятся в нём. В том числе и персонажи. Но как может быть юзер ассетом персонажа, я не очень понимаю.

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

Но этот посыл ровным счетом ничего не меняет. Все будет зависеть от глубины и ширины модели. Вот я к чему.
Пуш/пуль. Вот в чем камень преткновения! Когда push становится быстрее pull и наоборот? Никакие остальные рассуждения о конкретике реализации не имеют смысла. Вполне возможно, что эта величина вычислима на основе количества объектов, агрегируемых другим.

[Psycho Tiger]

Тем и плохо, что надо тянуть и не забыть.

Главная модель для меня всегда находится в вершине иерархии. Если композит моделей перенести на дисплей обджект, то это stage / root, ссылка тянется самой структурой.

[etc]

Сообщение от Psycho Tiger

Главная модель для меня всегда находится в вершине иерархии. Если композит моделей перенести на дисплей обджект, то это stage / root, ссылка тянется самой структурой.

А, я думал про «тянуть» имелось ввиду передавать вниз по иерархии. Если имеется ввиду сразу дергать линк, то ничего плохого в этом нет, кроме бесполезно потраченного времени.

[Psycho Tiger]

Сообщение от etc

А, я думал про «тянуть» имелось ввиду передавать вниз по иерархии. Если имеется ввиду сразу дергать линк, то ничего плохого в этом нет, кроме бесполезно потраченного времени.

Вниз - это от предка к потомкам?
Когда контейнеру делают addChild у него автоматом устанавливается parent и root. Когда нужен root - сразу дёргают root, без поиска его по ленивым геттерам. Где тут бесполезно потраченное время, не понимаю?

@Инквизитор: тебя я тоже совсем не понимаю )
Можно на пальцах?

[etc]

Сообщение от Psycho Tiger

Вниз - это от предка к потомкам?
Когда контейнеру делают addChild у него автоматом устанавливается parent и root. Когда нужен root - сразу дёргают root, без поиска его по ленивым геттерам. Где тут бесполезно потраченное время, не понимаю?

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

Добавлено через 50 секунд

Сообщение от dimarik

Но этот посыл ровным счетом ничего не меняет. Все будет зависеть от глубины и ширины модели. Вот я к чему.
Пуш/пуль. Вот в чем камень преткновения! Когда push становится быстрее pull и наоборот? Никакие остальные рассуждения о конкретике реализации не имеют смысла. Вполне возможно, что эта величина вычислима на основе количества объектов, агрегируемых другим.

Это всё можно реализовать гибридным способом, где-то push, где-то pull. Но сомневаюсь, что когда-нибудь этим займусь.

Добавлено через 1 минуту

Сообщение от incvizitor

Зачем сразу устанавливать рут? Разве его нельзя забрать рекурсивно?

В предложенном варианте будет пробегать всякий раз при обращении к геттеру. Это не есть гут.

[incvizitor]

Psycho Tiger, ну тогда получится что DataBase придется экстэндить, и все потомки (которые хотят обращатся к прототипам) будут знать тип нашей БД. А если использовать ленивый геттер, то мы не знаем что в иерархии является IPrototypeHolder у которой можно забрать прототипы.

[incvizitor]

Зачем сразу устанавливать рут? Разве его нельзя забрать рекурсивно?

На пальцах:

public function getPrototypeHolder():IPrototypeHolder{
     var parentNode:DataContainer = parent;
     while(parentNode){
          if(parentNode is IPrototypeHolder){
                return parentNode as IPrototypeHolder;
          }
          parentNode = parentNode.parent;
     }
     throw new Error("not found");
}

Мы не знаем что это именно ДБ явлеятся (ведь может быть и нет) IPrototypeHolder, мы просто знаем что он есть среди родителей.

[dimarik]

Позвольте все эти вышеозначенные вопросы свести все-таки к пушпулю. Итак, все рассуждения сводятся к тому, как красивше в дереве прокидывать ссылки на листья/ветки к другим листьям/веткам. Никто не находит это логичным?