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-16 23:48:03

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

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