Re: [boost] [Mixin] Some comments

Subject: Re: [boost] [Mixin] Some comments
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-01-10 20:05:33

On Sat, Jan 10, 2015 at 8:46 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

>
> First of all, I want to say that I like your library too much. It is quite
> close to a library I was working one EntityRoleSubject. You library could
> be extended to to take in account the subjective programming paradigm (see
> below).
>
> I have some comments/remarks/questions:
>
> * I have some doubts about the name mixin. What a mixin has more than a
> facet or an aspect? Mixins in C++ have a specific mean in the context of
> CRTP. Why have you chosen the mixin name?
>
>
I aree with this remark.
As I mentionned in previous discussions on this mailing list, it looks far
more like a "flexible but not performant" implementation the Entity
Component "pattern".
Wikipedia: http://en.wikipedia.org/wiki/Entity_component_system
Explainations about why it's used a lot in game engine code:
http://gameprogrammingpatterns.com/component.html

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).

> * 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<Mix_1, .... Mix_n> s (o);
>
> o.get<Mix_k>() works as expected.
>
> o.get<Other>() compile fails if not equal to any Mix_k
>
>
Interesting.

>
> * The entity-mixin relation is not recursive, that is, a mixin can not
> have associated mixins, or can them?
>
>
Usually it makes no sense, except if you mean that one mixin type require
another mixin type to be available for the object instance to work.
In which case I don't see a mechanism for automating this check in
Boost.Mixin, and I'm not sure if it's the right place for that.

> * 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?

> * The example of the mixin headphones_player show that the play()
> implementation makes use of get_sound() provided by other mixins. This
> dependency is not explicit. I would expect to be able to say that
> headphones_player depends on another mixing providing the get_sound message.
>
>
I believe that there are a lot of better (non game related) example for
such library.
A simple 3D space editor allowing to associate behaviours to 3D objects is
a good enough example and is very simple to visualize mentally.

> That's all for now.I will come back later when i will read more.
>
> A BTW, the reference documentation doesn't contain the add<M>/get<M>
> mutate functions?
>
> Best,
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>