Re: [boost] [Mixin] Some comments

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

On Sun, Jan 11, 2015 at 10:05 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> 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<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.
>>
> 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
>