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