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-12 19:23:40

On 8/13/10 3:19 AM, Stefan Strasser wrote:
> Zitat von Christopher Schmidt <mr.chr.schmidt_at_[hidden]>:
>
>>> a) the use of the word CLASS. This is inappropriate since that family of
>>> functions applies to a subset of classes and structs that use the getter
>>> setter idiom (GSI).
>>> b) the GSI is one of many possible idioms. One might also wish to
>>> include
>>> static member variables in the sequence, for example.
>>> c) I don't think GSI should have the same "status" as the STRUCT family
>>> since it is one of many possible idioms and one that is particularly
>>> bad (I
>>> can elaborate on why if someone wants).
>>>
>>> So, I suppose I would be in support of the CLASS family if it was
>>> renamed to
>>> GSI and put in a separate header for GSI support functions.
>>
>> The BOOST_FUSION_ADAPT_xxxCLASSxxx-macros are not exclusively limited to
>> getter and setter methods. Any expression that denotes to the given
>> lvalue or rvalue types may be used.
>>
>> float ff;
>> struct S{static int T;};
>> float& f(S){return ff;}
>> BOOST_FUSION_ADAPT_CLASS(
>> S,
>> (int&,int&,S::T,S::T)(float&,float const&,f(obj),f(obj))
>> )
>>
>> In this regard I like 'CLASS' as it implies a somewhat public interface
>> with a black box implementation.
>
>
> I don't think the fact that ADAPT_CLASS isn't limited to getter and
> setter _methods_, but allows get/set expressions, changes the argument.
>
> ADAPT_CLASS doesn't distinguish itself from ADAPT_STRUCT by what is the
> difference between c++ "class" and c++ "struct".
> I'd argue that it doesn't even adapt a class, but defines a fusion
> sequence from a series of c++ expressions.
>
> that might be a useful feature, and one useful variant of that feature
> might be a macro that defines "obj" for the scope of the expressions,
> but I think the naming is confusing. see my previous mail for a
> practical example.
>
> finding a name for this feature along the line of "define sequence from
> expressions" would also reduce the number of macros. I don't think the
> SUB-/DERIVED variants I proposed are needed for this.

C'mon guys! We're venturing into the name-game land!
If that's the game, then we should shout out why C++ confusingly
has "struct" and "class" anyway which both have very little nuance.
I don't want to go there. Sorry. This is not going to be another
bike-shed issue.

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