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

Subject: Re: [boost] [mixin] Introducing a new library.
From: Borislav Stanimirov (b.stanimirov_at_[hidden])
Date: 2013-02-05 16:40:20

На 05-Feb-13 21:56, Matus Chochlik написа:
> On Tue, Feb 5, 2013 at 8:18 PM, Borislav Stanimirov <b.stanimirov_at_[hidden]> wrote:
>> On 05-Feb-13 16:51, Matus Chochlik wrote:
[...]
>>>
>>> 2) Will it be possible through mutate::add<Mixin>() to add an existing
>>> instance
>>> of the Mixin, that could be shared among several objects ?
>>>
>>> For example, in a game that supports item modification, default unmodified
>>> items
>>> could share some common mixin that would manage the default properties,
>>> and when the item is modified this shared mixin would be replaced by an
>>> unique
>>> instance of the mixin specific to the particular modified item.
>>
>>
>> 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.

-- Borislav