Re: [boost] [Mixin] Some comments

On Sun, Jan 11, 2015 at 2:05 AM, Klaim - Joël Lamotte wrote:

On Sat, Jan 10, 2015 at 8:46 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

...

[8<]

Basically allow very flexible composition even at runtime (which helps tools dev too). It's also have been mentionned in the documentation after these discussions. (the doc is actually wrong in thinking that all engines component systems rely on inheritance by the way).

Last months I have seen mentionned several implemetnations of this pattern in C++11/14 on github but was not pleased with any design so far. The design of Boost.Mixin is close to what I want but don't reach my needs yet (or at least last time I looked at it).

I've been playing with some ECS designs lately and tried to implement two of my own [1],[2] (maybe those are among those you've already seen) (and sorry for the shameless plug). Based on what I've seen, if the ECS is to be used according to the usage patterns you usually see in a game (or rendering) engine, I believe it is better for the component instances to be stored together, outside of the entities (for locality of reference, efficient (re-)allocation, etc.). The entity should IMO be just an unique identifier and in both of my implementations there is a `manager` class that can be used to store/modify/query/remove/etc. the components of an entity. This way operations that are common, like execute this function (every iteration of the update loop) on all entities with this set of components can be implemented more efficiently.

From what I've seen in `Mixin` sources (quite some time ago, maybe it has changed in the meantime) it does not do this. But the Mixin docs state that it is not exactly an ECS and maybe its usage patterns are different.

...

* Respect to subjective programming: it would be great to be able to create subject from an entity so that only the mixins of the subject would play when a reference to this subject is addressed.

subject s (o);

o.get() works as expected.

o.get<Other>() compile fails if not equal to any Mix_k

Interesting.

In the [1] implementation you can do this by creating a `manager` that has a statically assigned group of component types. The usage is then close to the following: struct cmpnt_1 { }; struct cmpnt_2 { }; struct cmpnt_3 { }; struct cmpnt_4 { }; //declare group_x to contain component types cmpnt_1, cmpnt_2, cmpnt_3. manager m; entity e; m.add(e, cmpnt_1(...), cmpnt_2(...)); use(m.get(e).whatever); m.add(e); m.for_each(func); m.remove(e); m.add(e, cmpnt_4()); // compilation fails m.get(e); // compilation fails m.remove(e); // compilation fails But having implemented several apps using this approach I find it quite limiting in some situations that the group of components is static. Sometimes it is useful (for example for debugging) to have the ability to add/remove component *types* on-the-fly. [2] allows this but its unfinished. [8<]

...

* Can a mixin D inherit from another mixin B? Could the mixing D be retrieved when getting the mixing B?

mutate(o).add<D>;

o.get<B>()->f() // f been a virtual function on B?

I am failing to see the point or usefulness of this?

Most of the literature I've seen on ECS warns against trying too hard to combine OOP and the data-driven programming style used by E/C systems. Such logic should be encapsulated in the `systems` that work on the entity's components. But again maybe Mixin tries to fill a different niche than 'typical'/'traditional' ECS's do. [8<]

[1] https://github.com/matus-chochlik/exces [2] https://github.com/matus-chochlik/eagine/tree/develop/include/eagine/ecs BR Matus