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

Subject: Re: [boost] [mixin] Introducing a new library.
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2013-02-05 14:56:17

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:
>>
[...]
>> I've been playing with the library and I would like to ask a couple of
>> questions:
>>
>> 1) Is it (/will it be) possible to check is a specific message can be sent
>> to an object, instead of checking for mixin type.
>
>
> Yes, quite easily. I don't even know why I haven't added it by now. It's
> literally 6 new lines of code in the current repo. The syntax will be
> `obj->implements(some_message_msg);`
> In the basic example from the repo `o->implements(render_msg)` will always
> return true (since all  objects implement that message).
>
> The problem is that my PC broke yesterday, and I won't be able to push this
> until Friday (my workplace's proxy server hates github and I can't do it
> from here). However if you want this, I could send you a patch for it.
>

Thanks,I suspected that it should be easy but, I didn't find it
anywhere in the code.
I'll wait till Friday then, or if it's not a big problem please send
me the patch.

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

>
> Still I have to think about this some more, and I might add a feature that
> will help in such cases (as they do seem common). But I'm not sure if it
> would be possible to implement something like that gracefully. In any case,
> this feature, if it even comes to existence, won't be available soon.
>
>
>>
>> 3) Will some kind of "message overloading" be supported? For example:
>>
>> class named
>> {
>> private:
>>    string _name
>> public:
>>    void name(const string& new_name){ _name = new_name; }
>>    const std::string& name(void) const { return _name; }
>> };
>>
>> BOOST_DECLARE_MIXIN(named);
>>
>> BOOST_MIXIN_CONST_MESSAGE_0(const string&, name);
>> BOOST_MIXIN_MESSAGE_1(void, name, const string&, new_name);
>>
>> ...
>>
>
> Yes but not quite in the way you suggested. I had message overloading in
> mind since the start and all provisions have been made for this feature and
> it would really take probably half an hour to implement in the current repo.
> The main problem is that it's impossible to have messages of the same name.
> So here's how your example will work after I add the changes:
>
>   BOOST_MIXIN_CONST_MESSAGE_0(const string&, name);
>   BOOST_MIXIN_MESSAGE_1_OVERLOAD(name_setter, void, name, const string&,
> new_name);
>   //                               ^                  ^
>   //                          message name | actual method name
>
> or alternatively:
>
>   BOOST_MIXIN_CONST_MESSAGE_0_OVERLOAD(name_getter, const string&, name);
>
>   BOOST_MIXIN_MESSAGE_1(void, name, const string&, new_name);
>
> or even:
>
>   BOOST_MIXIN_CONST_MESSAGE_0_OVERLOAD(name_getter, const string&, name);
>   BOOST_MIXIN_MESSAGE_1_OVERLOAD(name_setter, void, name, const string&,
> new_name);
>
> and then in the mixin definition:
>
>   BOOST_DEFINE_MIXIN(named, name_setter_msg & name_getter_msg);
>   // we use the message names here
>

Ok, the "registering" syntax is not too important, if it works.

> after all that, calling the messages will be by the actual method name so
> the code:
>
>   name(o, "Hildegard");
>   cout << name(o); // outputs Hildegard
>
> will work just as regular function overloads.
>
> To check for implementation, you'll have to call
> `o->implements(name_setter_msg)`

BR,

Matus