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

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-08-15 20:11:47

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.

-Stefan