На 05-Feb-13 21:56, Matus Chochlik написа:
On Tue, Feb 5, 2013 at 8:18 PM, Borislav Stanimirov <b.stanimirov@abv.bg> 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