Re: [Boost-users] [Fusion] Associate arbitrary compile/runtime annotations with members of fusion sequence

Subject: Re: [Boost-users] [Fusion] Associate arbitrary compile/runtime annotations with members of fusion sequence
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-02-24 19:07:52

On 2/25/13 6:31 AM, Kozlov Taras wrote:
> 24.02.2013 6:46, Joel de Guzman пишет:
>
>>> 7. Generic question about adapt macroses in fusion.
>>>
>>> I used BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF to define has_annotations
>>> metafunction that
>>> determine if type members were defined with CPPAN_DECLARE_AND_ANNOTATE.
>>> Then I wrote fusion extension which enables for arbitraty type if
>>> has_annotations<T> is true.
>>>
>>> This approach allowed to move CPPAN_DECLARE_AND_ANNOTATE inside of
>>> struct definition.
>>>
>>> Can BOOST_FUSION_DEFINE_STRUCT be reimplemented in that way? This will
>>> allow to get rid of
>>> namespaces sequence and struct_name parameters. I believe this will
>>> also make needless
>>> _TPL and _INLINE versions of BOOST_FUSION_DEFINE_STRUCT macroses.
>>>
>>> Are there any compiler portability or design problems with such approach.
>>
>> I'm not sure at the moment about the implications. If the tests pass,
>> then that's
>> a good indication that it's good.
>>
>> To be honest, the fusion macros need a lot of time, attention and love
>> right
>> now. I'm not quite happy with the way they are implemented, to be frank.
>> Just
>> reading the code drives me nuts! It seems that you know your way around the
>> macros. If you could find a good way to clean them up, then we should talk.
>>
>> I'd love to see your extensions added, of course if you are interested in
>> contributing and maintaining them; along with the other adapt/define macro-
>> siblings. If you are interested, it would be crucial to have symmetry and
>> uniformity. Thus to follow up on my answer above (***), if you intend to
>> somehow have your code assimilated in fusion, then we cannot break the
>> precedent and have a new way of doing things because that will confuse
>> users.
>>
>> Regards,
>
> Well, I guess most of people would be happy to contribute something usefull into Boost,
> and I`m not an exception here :)
>
> Here is how I see next generation of define and adapt macroses in fusion:
>
> 1. Intrusive.
>
> BOOST_FUSION_DECLARE_MEMBERS(
>     (base_type0)(base_type1)...,
>     (member_type0, member_name0)
>     (member_type1, member_name1)
>     ...
> )
>
> BOOST_FUSION_DECLARE_ASSOC_MEMBERS(
>     (base_type0)(base_type1)...,
>     (member_type0, member_name0, key_type0)
>     (member_type1, member_name1, key_type1)
>     ...
> )
>
> Example:
>
> struct name_key;
> struct age_key;
>
> struct D : B1, B2 {
>      BOOST_FUSION_DECLARE_ASSOC_MEMBERS(
>          (B1)(B2),
>          (std::string, name_, name_key)
>          (int, age_, age_key)
>      )
> };
>
> I believe we can easily reimplement current adapt macroses
> BOOST_FUSION_DEFINE_STRUCT
> BOOST_FUSION_DEFINE_TPL_STRUCT
> BOOST_FUSION_DEFINE_STRUCT_INLINE
> BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE
> BOOST_FUSION_DEFINE_ASSOC_STRUCT
> BOOST_FUSION_DEFINE_ASSOC_TPL_STRUCT
> on top of them
>
> Having BOOST_FUSION_DECLARE_ASSOC_MEMBERS will also make implementation of
> CPPAN_DECLARE_AND_ANNOTATE trivial.
>
> 2. Non-intrusive
>
> As far as I see, each BOOST_FUSION_ADAPT_* macro should have _WITH_BASE paired macro with
> additional base type sequence parameter.
>
> BOOST_FUSION_ADAPT_STRUCT_WITH_BASE(
>      struct_name,
>      (base_type0)(base_type1)...,
>      (member_type0, member_name0)
>      (member_type1, member_name1)
>      ...
> )
>
> I think I should move forward step by step:
>
> 1. Implement
> BOOST_FUSION_DECLARE_MEMBERS
> BOOST_FUSION_DECLARE_ASSOC_MEMBERS
>
> 2. Implement the most complex case from non-instrusive macroses. I guess that can be
> BOOST_FUSION_ADAPT_ASSOC_TPL_ADT_WITH_BASE
>
> Hope this will help to get complete view of common implementation details between
> instrusive and non-instrusive macroses.
>
> 3. Reimplement current instrusive macroses based on new BOOST_FUSION_DECLARE_MEMBERS
>
> 4. Other version of _WITH_BASE non-intrusive macroses
>
> 5. Trivial reimplementation of current non-intrusive macroses based on _WITH_BASE versions.

Sounds wonderful! I'd also wish for a lot more tests, if you will :-)
Let us follow up on this offline. Feel free to email me directly.

Regards,
-- 
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/