Re: [boost] [Mixin] Some comments

On Sun, Jan 11, 2015 at 10:05 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

Le 11/01/15 02:05, Klaim - Joël Lamotte a écrit :

...

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

Instead of subject I should be used view. A subject must have the listed mixin. You can be interested in reading this old paper

Roles: conceptual abstraction theory and practical language issue

Bent Bruun Kristensen and Kasper sterbye

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web& cd=2&cad=rja&uact=8&ved=0CC8QFjAB&url=http%3A%2F%2Fwww.itu.dk%2Fpeople% 2Fkasper%2Fpapers%2Fosterbye_R8.pdf&ei=QjWyVMO4CoaaygOC4YCQBA&usg= AFQjCNEczlV4c-61kWGJ_qoUe0AhDGhRYg&sig2=PKFjzFly_ B9jvY26uNLKcA&bvm=bv.83339334,d.bGQ

Thanks, will read.

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

Yes this is what I mean.

...

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.

It seems this is achievable at run-time adapting the mutation rules. :( I'm locking for something that can be checked at compile-time.

Maybe by requiring mixins to provide a typedef tuple of other mixin types they require to be present? That might be an ugly solution though.

...

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

If suggest you to read the paper. In principle as for classes, the user must be able to specialize mixins. I'm not talking about the Game domain that don't know and for which maybe this is not what they need. You can think of a class This is needed when you associate a mixing to a specific kind of entity. The Mixin library don't classify the entities, something that I'm locking for. Having a classification of Entities, it is reasonable to state which roles/facets/subjects/mixins it can support. This allows to have a first compile type checking. A specialized entity could require a specialized role.

entity B {}; entity D : B {};

B role X {}; D role Y : X {};

Would something like the translation tables of MSM work? Just stating the relationship between mixn types.

...

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

I'm sure you are right, and that the library has its value. I find, however that this framework don't help to force compile type integrity. If the entity don't has an associated mixing that plays the get_sound function, the user will get an exception in the best case. When we work with strongle typed languages as C++ we expect something better.

Indeed.

Vicente

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost