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

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: David Sankel (camior_at_[hidden])
Date: 2010-08-12 13:32:58

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.

David

-- 
David Sankel
Sankel Software
www.sankelsoftware.com
585 617 4748 (Office)