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-16 17:10:25

Joel de Guzman schrieb:
> On 8/16/10 8:11 AM, Stefan Strasser wrote:
>> Zitat von Joel de Guzman <joel_at_[hidden]>:
>>
[snip]
>> 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 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.

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.

Just my 2 cents.

-Christopher