Experimenting with different data structures types about ash

[Glidias]

I guess regarding DLL or any data structure thereof, having an onAddedNode/onRemoveNode hook would be required if nodes are going to be reused, since a given System would have to listen to those hooks in order to initialize/reset a given node.

After all, the data structures are not mean't to be updated directly, but through the Game. Which is why NodeLists add/remove methods are internal.

A doubly-linked list i guess is the most versatile. After all, even a RenderingSystem could still benefit greatly with a doubly-linked list, since one could listen to the NodeList's onRemoveNode(node:RenderNode) trigger to handle removing of Object3D nodes easily within a singly-linked list rendering engine (eg. Alternativa3D, as it doesn't know what the "previous" Object3D would be (a3d only has a next:Object3D pointer), while a doubly-linked list system would allow for such a quick removal that wasn't even supported by the engine itself (eg. node.previous.obj.next = node.next.obj) ). onAddNode() can be used to reset a given node values in various other systems.

[richardlord]

Thank you for your thoughts. It will take a while to digest them all. Here's my take on the two direct questions you ask.

Q1 - Yes, the only time we need to protect the removed node is during the list iteration. As you say, the system could be responsible for locking and unlocking the list, but that would require developers using the library to know more about the inner workings of Ash, and to remember to lock lists when iterating. That's why I prefer the framework doing a conservative lock during game update.

Q2 - The nodeAdded and nodeRemoved signals are used in systems to do one-off actions on nodes, like adding display objects to the display list in the render node of the Asteroids example. They're not used by the family because the family manages the objects in the list directly. i.e. if a node is added or removed, it is added or removed by the family, so the family doesn't need to use the signal.

[Glidias]

Anyway, here's the Haxe branch folder with the data structure generics. It's called HashDS. Not complete, obviously.

https://github.com/Glidias/Ash/tree/master/hx/hashds

One thing i dislike about Generics is the potential code bloat just to support strict-typing. Thus, a dynamic fall-back should always be considered. Same with inlining. But both practices are useful in cases where one wishes to avoid duplicating typed code.

Anyway, in my wip modification port of Ash to Haxe (I call it HashDS), here's a wiki considering paradigms on how hashing/storage of Family ownerships can be done within Ash/HashDS.

https://github.com/Glidias/Ash/wiki/HAsh-DS-exploration-notes

[Glidias]

Anyway, I deleted the Ash fork and created a completely new repo instead for the Haxe port/modification.

Here it is, presenting HashDS:
https://github.com/Glidias/HashDS