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

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Christopher Schmidt (mr.chr.schmidt_at_[hidden])
Date: 2010-08-20 14:58:07

Joel de Guzman schrieb:
> On 8/17/2010 5:10 AM, Christopher Schmidt wrote:
>>>> 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 don't agree. The proxy is indeed clumsy, but due to being implicitly
>> convertible to the underlying type it does its job quite well. In most
>> use-cases an adapted 'class' does feel just like any other regular
>> fusion container.
>> In my opinion, fully exposing the proxy type is not conducive as the
>> type of interest is always the type encapsulated by the wrapper. The
>> proxy is just a means to an end.
>> If the special traits of proxies are ditched, that is if the implicit
>> conversion ability is removed and the proxy is exposed as the actual
>> value type, all generic user code will need to handle proxy types
>> explicitly. Generic user tmp code would probably need hacky mpl-code
>> that distinguishes fusion proxies from non-proxy value types. Generic
>> run-time functors would need to be specialized for proxies. That is
>> prone to errors! With the current design, only very few run-time
>> functors have to be specialized for proxies at all.
> 
> Also very good points. I think the proxy should behave similar to
> Boost ref, as it should expose an implicit conversion to T. This alone
> will satisfy many code that expects T. As for exposing the proxy as
> the value type of the sequence, you are right. However, what we can
> probably do is to be consistent with handling const and non-const
> and always return a proxy so there is no surprise when code works
> one way and not the other way.

I agree.

> 
>> Stefan, considering your special use-case: if the proxy's underlying
>> value type is exposed as the real value type of the sequence, you don't
>> need to specialize your functor at all. See the attached code -
>> ref_for_each is an implementation of fusion::for_each that internally
>> resolves proxy types. Such an approach hides the proxy completely!
>>
>> I do not see how fully exposing the proxy leads to simpler or less error
>> prone code. Therefore I vote for keeping the interface as it is - with
>> the proxy type being documented and its semantics fully exposed to the
>> user.
>> As for the name, I do like ADAPT_EXPR or ADAPT_ADT more than ADAPT_CLASS.
> 
> My problem with this approach is that you need special algorithms to
> deal with these proxies. It may not be a bad idea to embrace proxies
> (and reference wrappers) library wide as intrinsic to our concepts,
> so that proxies will be totally transparent, but I am not quite sure
> if it's worth it. It's an additional burden for algorithm writers
> to deal with.

Well, that is a *lot* of work - and such an approach does not hide the
proxy completely. The return type of fusion::deref is still a proxy.

I think we should proxify the 'const' return type and rename
BOOST_FUSION_ADAPT_xxxCLASSxxx to BOOST_FUSION_ADAPT_xxxADTxxx .
BOOST_FUSION_ADAPT_xxxEXPRxxx breaks ranks as EXPR does not relate to
the adaptee at all. boost::fusion::extension::class_member_proxy<T>
should be changed to boost::fusion::extension::adt_attribute_proxy<T,
B>, with B being a boolean constant that is true for lvalue and false
for rvalue proxies.
The drawbacks of proxies should be pointed out explicitly in the
documentation, including a short abstract that advocates adapting
abstract data types using fusion's native extension mechanism in order
to avoid the proxy.

Are there any objections to these changes? Stefan, is this acceptable
for you?

-Christopher