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-11 23:29:18

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.

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