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

Subject: Re: [boost] [mixin] Introducing a new library.
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2013-02-06 09:57:51

On Tue, Feb 5, 2013 at 10:40 PM, Borislav Stanimirov
<b.stanimirov_at_[hidden]> wrote:
[...]
>>>
>>>
>>> No. Mixin instances are bound to object instances. That's why `bm_this`
>>> (pointer to the owning object) is possible. If objects could share mixin
>>> instances, `bm_this` would be ambiguous (not to mention impossible to
>>> implement if we want to keep things non-intrusive).
>>
>>
>> Hm
>>
>>>
>>> The example you gave could be implemented in two ways:
>>> 1. With an item holder mixin that holds a pointer to either a shared
>>> unmodified item or to its own instance of a modified item.
>>
>>
>>> 2. With two mixins: `unmodified_item`, which again holds a pointer to the
>>> shared unmodified item, and `item` which represents a modified one. As
>>> long
>>> as both implement the same messages everything will work fine.
>>
>>
>> I actually tried some variations on these approaches, it works, but it
>> does not
>> scale very well since you have to write a lot of code that just forwards
>> the messages and this usage pattern is quite common.
>>
>
> A longer reply to this point:
>
> I realize that this could be a commonly requested feature and that it is
> supported in at least some entity component systems, but I'd argue that this
> isn't what "mixin" is. Mixins are not references to objects a class can
> contain. They are the actual building blocks of the class. If you have
> changed and unchanged items, those are different instances (possibly the
> same class). So, the politically correct way of implementing this would be
> to have different object instances (consisting of the same mixins) for those
> kinds of items.
>
> Now I also realize that this means that you have to copy all of the object's
> data, unrelated to its... er... itemness, when you decide to change an item
> and that's unpleasant, but it seems that (generally speaking) mixins are not
> something that can help you there. You'd have to go and implement it in the
> way you would have, if you didn't have mixins available. Either in the
> aforementioned way, or, possibly, if you don't want to copy the interface,
> by adding a simple `get_item` message. It may return `item*` or it may even
> return `object*` allowing you to have other mixins in an item, specific for
> this instance.

>
> I am still going to think of how this could be addressed in some way in the
> library (and whether it should), but for now this seems highly unlikely.
>

After looking at the implementation I now understand why this could
be a problem. Anyway if you come up with some solution, this feature
would be nice to have.

There are also a couple of things I would like to suggest:

1) Please add perfect forwarding (std::forward) to the macros and the caller#
functions in gen/message_macros.ipp so that properties can be move-assigned.

2) Would it be possible to have object.implements<message>() in addition
to object.implements(message_msg). IMO the former is more generic.
>From a glance at the implementation this would require some changes
to the representation of messages, but it should be doable.

3) Please add <some-message>(object&, <other-params>) in addition to
<some-message>(object*, <other-params>), if possible.

thanks,

Matus