Re: [boost] [mixin] Introducing a new library.

Subject: Re: [boost] [mixin] Introducing a new library.
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-31 13:58:33

Le 31/01/13 08:44, Borislav Stanimirov a écrit :
> On 01/31/2013 09:30 AM, Vicente J. Botet Escriba wrote:
>> Le 30/01/13 20:53, Borislav Stanimirov a écrit :
>>> Hello,
>>>
>>> Boost.Mixin is a library I'm developing with the idea to someday
>>> submit it to Boost.
>>>
>>> It is an entity-component system, with full abstraction between
>>> interface and implementation.
>>>
>>> [... snip ...]
>>> Here is a github link to the library: 
>>> http://github.com/iboB/boost.mixin
>>> A working example can be found here:
>>> http://github.com/iboB/boost.mixin/tree/master/libs/mixin/example/basic
>>>
>> Hi,
>>
>> IIUC your library is related to the subject-role [1] but a mixin is more
>> an aspect of an entity than a role.
>>
>> Could the user define a typed subjects, that is an entity that has some
>> specific mixins?
>
> Right now this is possible with the object_transformer class, wich 
> allows you to manually add specific mixins to an object (or remove 
> them). A planned feature is to have object type templates, where just 
> calling `new` will create an object with a list of specific mixins
By typed subjects I meant a class that could check at compile time that 
the mixins that can be added belongs to a list of types. Something like

subject<E, M1, M2> s;

s.add<E>().add<M1>().add<M2>(); // Ok.

s.add<AnotherType>(); // compile fails

IIUC your library is not strongly typed (based on Smalltalk message 
paradigm).

I would be more interested in a library that reach to manage with static 
typed mixins that doesn't compile when a mixin is not on the list of 
mixins, but I don't see how both approaches could conciliate.
>
>> Could the user see an object restricted to some of his mixins?
>
> This is a planned feature too. Also automatically injecting specific 
> mixins. Also automatically replacing given mixins with others.
>
I meant something like

subject<E, M1, M2> s;
s.add<E>().add<M1>().add<M2>(); // Ok.
subject_view<E, M1> sv(s);
// Now any specific message m2 of mixing M2 sent to sv should not compile.
// Now any multicast message sent to sv would take in account only E and M1.

BTW, the function add() could let think that the same mixin type could 
be added several time, but I suspect that this is not the case. Maybe 
set() could be more appropriated.

I have found the name mixin on other context where mixins are staked the 
ones on top of the others (look for GenVoca on www or [1]). The 
structure of a mixin is something like

template <typename Final, typename Derived>
struct Mixin : Derived
{
   void specific_message() {
    // do something
   }
   void multicast_message() {
    // do something
    this->Derived.multicast_message();
   }
};

With this architecture, the responsability for multicast is shared by 
all the mixins by forwarding to the next mixin. Of course this 
architecture doesn't respond to your needs, as the mixins are fixed at 
compile time but maybe this could inspire you to adapt your library to 
be able to manage with user defined multicast messages and improve the 
performances and the memory footprint.

HTH,
Vicente

[1]/Generative Programming/ : /Methods/, /Tools, and Applications/ by 
Krzysztof Czarnecki