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-12 14:18:22

David Sankel schrieb:
> On Wed, Aug 11, 2010 at 11:29 PM, Joel de Guzman
> <joel_at_[hidden]>wrote:
> 
>> On 8/12/10 9:46 AM, David Sankel wrote:
>>
>>> On Sat, Jul 31, 2010 at 9:02 AM, Christopher Schmidt<
>>> mr.chr.schmidt_at_[hidden]>  wrote:
>>>
>>>  Joel de Guzman schrieb:
>>>>
>>>>> On 7/30/2010 6:35 AM, Stefan Strasser wrote:
>>>>>
>>>>>> Zitat von Hartmut Kaiser<hartmut.kaiser_at_[hidden]>:
>>>>>>
>>>>>>> Have you seen the new BOOST_FUSION_ADAPT_CLASS() family of utilities
>>>>>>> which
>>>>>>> allow using (member-) functions instead of direct access to the data
>>>>>>> members
>>>>>>> of a class/struct?
>>>>>>>
>>>>>>
>>>>>> no I had not, I was using 1.41. where can I see those? can't seem to
>>>>>> find them in 1.43 or
>>>>>> the trunk.
>>>>>>
>>>>>
>>>> The BOOST_FUSION_ADAPT_xxxCLASSxxx-macros are not documented yet. For
>>>> more information, refer to the code and the testcases:
>>>>
>>>> https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/adapted/class
>>>> https://svn.boost.org/trac/boost/browser/trunk/libs/fusion/test/sequence
>>>>
>>>>
>>>> https://svn.boost.org/trac/boost/browser/trunk/libs/fusion/test/sequence/adapt_class.cpp
>>>>
>>>
>>>
>>> I think the ADAPT_CLASS macros fundamentally change the expected behavior
>>> of
>>> struct adaptation in a negative way. A non-template class/struct is a
>>> collection of
>>>
>>>  a) types (declared as nested typedefs or other structs)
>>>  b) values of the following variety
>>>       i) static member variables (values that are non-functions)
>>>       ii) static member functions (values that are functions)
>>>       iii) member functions (values that are "special" functions over the
>>> instance record)
>>>  c) an instance record, which includes member variables
>>>
>>> Up until this point, struct adaptation has exclusively been over the
>>> instance record, point c) above. This is very simple to understand and
>>> implies exactly one canonical adaptation for every struct/class.
>>>
>>> ADAPT_CLASS mixes point c) and point iii) in an arbitrary way. Stefan's
>>> suggestions, on the other hand, are a straightforward extension of the
>>> original semantics. I'd personally like to see the latter incorporated and
>>> the former removed.
>>>
>>
>> What's wrong with having both? Non-intrusive class adaptation, IMO, is
>> very important too. I like Stefan's suggestions too but I don't understand
>> why we can't have both.
> 
> 
> I've given this some further thought and I think my problems are:
> 
> 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.

-Christopher