Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Joel de Guzman (joel_at_[hidden])
Date: 2010-08-15 20:39:06

On 8/16/10 8:11 AM, Stefan Strasser wrote:
> Zitat von Joel de Guzman <joel_at_[hidden]>:
>
>> On 8/16/10 1:01 AM, Stefan Strasser wrote:
>>> Zitat von Joel de Guzman <joel_at_[hidden]>:
>>>
>>>> class foo
>>>> {
>>>> public:
>>>>
>>>> int x() const;
>>>> void x(int n);
>>>> int y() const;
>>>> void y(int n);
>>>>
>>>> private:
>>>> // encapsulated
>>>> };
>>>>
>>>> Now, adapt that class to fusion.
>>>
>>> is the goal a (mutable) fusion sequence with value type int?
>>> then there is no solution, as the class only exposes the value of its
>>> members.
>>> if the goal is just any representation of the class in sequence form,
>>> I'd suggest to make the (now transparent) proxy object visible to the
>>> user.
>>
>> [snip]
>>
>> And as a matter of fact, that IS the intent. The proxy object is a public
>> class in namespace boost::fusion::extension named class_member_proxy
>> (terser
>> name suggestion welcome).
>
> ok, I missed the public proxy.
> I don't want to beat this to death, since I'm only going to use
> ADAPT_STRUCT the name of it is really the only thing that concerns me.
>
> so don't bother to reply to each of these points in detail, just give it
> another thought:
> - the proxy is implicitely convertible to/from values
> - const sequences are iterated as T, not as proxy<T const>
> - I think the value types of the sequence are T, not proxy<T>
>
> each of these points seem to try to hide the proxy from the user, while
> we agree that it can't be hidden completely.
>
> I think simply providing a sequence of proxies is less error-prone than
> trying to hide it when possible.
> the example I used in a previous email would then outright fail until
> support for proxies is added, as opposed to work in one case and fail in
> another, very similar, case.

Those are very good points. I await for Christopher's reply. I think
what you gave is a reasonable strategy. I like it.

I really hope that despite our disagreements, we can move forward
now. We really need the features that you provided that started this
thread (e.g. inheritance and optional intrusive adaptation). I hope
we can incorporate them into the code that we have now.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net