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

Subject: Re: [boost] [mixin] Introducing a new library.
From: Borislav Stanimirov (b.stanimirov_at_[hidden])
Date: 2013-01-31 14:29:58

On 01/31/2013 08:58 PM, Vicente J. Botet Escriba wrote:
> 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.

Aha. I get it now. In this case, no. The main purpose of the library is 
"live" object mutation. Compile-time types while maintaining the 
previous goal are not planned.

And yes. Smalltalk was one of the main inspirations for the library.

Anyway (at least at first glance) the code you write will sort of 
possible be possible to implement within the library but then the user 
code will suffer.

For example having collections of objects requires them to have the same 
type. For your code to work, one could have a common parent to all 
objects, say `parent`, but then nothing could stop the users from writing:

parent& p = o;
p.add<AnotherType>;

Having truly strongly typed objects defies the purpose of the library 
entirely.

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

Messages are in no way bound to a specific mixin. Hence they are 
dynamically dispatched. The compiler doesn't know (and has no way of 
knowing) which messages M2 implements. So for this one, again, no.

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

The function add is chosen, because one adds a mixin to objects. I guess 
"set" would imply that without calling it something remains "not set", 
which is not the case.

Calling `add` constructs a new type with this mixin present and assigns 
it to the object, thus you might say (this is simplified) that an object 
with mixins M1 and M2, takes up sizeof(M1) + sizeof(M2) memory, whereas 
and object with mixins M1, M2, and M3 takes up sizeof(M1) + sizeof(M2) + 
sizeof(M23). This is indeed adding.

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

I guess this design is exactly the opposite of what I'm trying to 
achieve. My library's goal is abstraction. Message clients don't know 
anything about the mixins. They only know messages. See here:

http://github.com/iboB/boost.mixin/blob/master/libs/mixin/example/basic/main.cpp

This is the main function of the basic example of the library. It calls 
different messages, without knowing anything about the mixins that may 
or may not be included in the object.

So, in short. I'm afraid that no compile time checks (of types, or 
implementations) will be present in this library.

-- Borislav