Add support for collection-backed properties

Issue #58 resolved
Michael Ludwig
repo owner created an issue

Currently Components that store collections of things must expose the base collection awkwardly. It would be nice if there could be addFoo() and removeFoo() methods that operate on the collection in place of the limited getters and setters for properties. Could similarly have hasFoo() and getAllFoos(), and maybe even clearFoos().

These methods would have well-defined semantics based on the selected backing collection type (either set, list, or map). Map would require a different set of collection methods (setFoo and getFoo that take the key object).

Additionally, it would be nice if there could be optimized property stores for collections that flatten them out into the array for limited collection sizes, or in the event that its a collection of components or entities, is somehow able to refer to their id instead of the instance.

Comments (9)

  1. Michael Ludwig reporter

    This is almost completed, but there have been some reasonably big changes that were necessitated by it so I wouldn't work on the snapshot version just yet. Basic map, list, and set support is in with the ability to do add(E), remove(E), contains(E), put(K,V), and get(K). There are a number of return type options for these (return nothing, return a boolean changed status, return the old element, or return the component for method-chaining). Not all return options are available for every collection type.

    I do not think I'll do generally optimized property stores, but I do think I'll still add custom collection implementations for components and entities.

  2. Michael Ludwig reporter

    After more thought, I do not think entities and components deserve custom collections. With the current internal structuring, trying to store the lists as integers is not much more efficient (and could likely be worse) than storing references to the entities or components. The only other feature a custom collection would have is to ensure that flyweight instances are not added to a collection. However, this adds substantial overhead and constraint checking and in many cases a non-flyweight instance is already on hand. Therefore, I've made it harder to accidentally get a flyweight instance (e.g. calling EntitySystem.iterator(Class<? extends Component>) so the only way to get a flyweight instance is explicitly requesting a fast iterator.

  3. Log in to comment