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

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-08-12 15:19:54

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.