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
>>> of the Mixin, that could be shared among several objects ?
>>> For example, in a game that supports item modification, default unmodified
>>> 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
>>> 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).
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk