Re: [boost] [Mixin] Some comments

Subject: Re: [boost] [Mixin] Some comments
From: Borislav Stanimirov (b.stanimirov_at_[hidden])
Date: 2015-01-11 02:50:22

On 10.1.2015 г. 21:46 ч., Vicente J. Botet Escriba wrote:
> Hi,
>
>
> 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?
>

The name is chosen to match the term mixin in Ruby. Ruby was the 
inspiration for the library. I though about naming it "component" or 
"dynamic polymorphism" or even something vague like "hameleon" or 
"zeus". Do you have any other suggestions for a name?

> * The construction of the mixins in the tutorial is done always with the
> default constructor. Can we do emplace construction? How can you ensure
> the invariants of some mixing classes?
>

For now a default constructor is a requirement for the mixins. I know 
how to proceed in order to have non-default constructors, and it is in 
the roadmap so this is an upcoming feature for sure.

> * The priority of the messages doens't compose well. The user needs to
> have a global view of the application so that it can assign the correct
> priority. I have not a better suggestion, but I think that this issue
> would need more insight.
>

I have thought about that, too. I will continue to think of a better way 
to assign priorities. For now in the software I've written with the 
library I use enums with elements like "mixin_x_message_y_priority" or 
"message_x_low_priority"

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

This subject class can be made, but it won't have a relation with the 
boost::mixin::object class. `object` is not a template class and I don't 
want to make it one. Such a functionality could be added to the object 
class if the error is run time and not compile time. I have some 
upcoming features which will introduce somewhat similar behavior - the 
multiple domains.

I'm not sure why this is a desired feature. How is this any different 
from simple inheritance or composition without any templates?

> * The macro bm_this :(
>

Is the name a problem or the fact that it's a macro? :)

> * I would like to see what is behind the scenes the different macros in
> an implementation section.
>

That's a good idea to add in the documentation. I'll add it to the 
upcoming tasks for the library.

> * The entity-mixin relation is not recursive, that is, a mixin can not
> have associated mixins, or can them?
>

I'm not sure what you're asking. A mixin can have associated mixins via 
mutation rules (see 
http://ibob.github.io/boost.mixin/boost_mixin/tutorials.html#boost_mixin.tutorials.mutation.mrules 
)

But I wouldn't call this recursive. It's more like a sibling (or enemy) 
connection.

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

A mixin can inherit from another as any class can but it can't be 
obtained via get<Parent> (or receive messages automatically). Inheriting 
a mixin from another is not registered or noticed by the library. To the 
library those are like any two unrelated classes.

You could easily implement that feature via a message. Let's say you 
have a class `behavior` and two children `enemy_behavior` and 
`friendly_behavior`. You chould add a method to the children

behavior* get_behavior() { return this; }

Then you could make it into a message and use code like:

::get_behavior(some_object)->f()

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

You could add a dependency on a concrete mixin via the mutation rules as 
mentioned above, but that will prevent you from having polymorphism for 
get_sound, as illustrated in the example by the two sound providers: 
cd_player and mp3_player. A compilation error is impossible for such a 
case. The exception thrown if an object doesn't implement a message is 
bad_message_call.

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

Get is documented here: 
http://ibob.github.io/boost.mixin/boost/mixin/object.html#idp9180592-bb 
(numbers 2 and 3)

Add/remove is not a member of object because the mutations are done by 
mutators. And you're right that they're not documented. I'll fix this on 
Monday.

Thanks for the interest and I look forward to hearing from you :)

-- Borislav