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-23 21:46:35

On 2/24/13 7:38 AM, Kozlov Taras wrote:

> Hi Joel,
> Thanks for ideas on "annotations". I`m going to apply them, but first I want to clearify
> some points, fix me were I`m wrong
>
> 1. Having structure A defined like following
> struct A
> {
>      CPPAN_DECLARE_AND_ANNOTATE(
>          ((int, int_field_,
>              ((int_annotation, 42))
>              ((string_annotation, "Hello world"))
>          ))
>          ((std::string, string_field_,
>              ((no_serialization, std::true_type()))
>              ((no_hash, std::true_type()))
>          ))
>      )
> };
>
> you want to see it as fusion Associative Sequence, where int_field_ will have key type,
> something like A::key_int_field_, right?

That's one way, alright. There can be other ways, but I haven't thought
about them very well.

> 2. Iterator for A struct will sequentally dereference to
> fusion::pair<key_int_field_, int>
> fusion::pair<key_string_field_, std::string>

Yep.

> 3. Members can be accessed directly or using fusion::at_key
> A a;
> at_key<key_int_field_>(a);

Yep.

> 4. I guess the most straightforward way to assign runtime values for annotations is to
> make them as members in key type.
> struct A
> {
>      struct key_int_field_
>      {
>          int int_annotation;
>          const char* string_annotation;
>
>          key_int_field_() :
>              int_annotation(42), string_annotation("Hello world") {}
>      };
> ...
> };
> Do you have any objections here?

A more generic approach is simply to treat annotations as just another
trait. That way, it can be a lot more flexible. You just specialize
a specific trait. Say traits::annotation_of<key_int_field_>:

     template <>
     struct annotation_of<key_int_field_>
     {
         int int_annotation;
         const char* string_annotation;

         key_int_field_() :
             int_annotation(42), string_annotation("Hello world") {}
     };

> 5.
> CPPAN_DEFINE_MEMBER_DETECTOR(no_hash);
> defines metafunction that will accept key type.
>
>      has_no_hash<A::key_int_field_>

Yep. Same.

> This metafunction can be specialized for any other key type. Is it ok? The question arise
> because you wrote
>
>      traits::has_no_hash<T, MK> where
>
> T - is member type
> MK - is key type

Forget what I said. Wit a member-key T is no longer needed.

> I haven`t got the idea behind passing member type here, from my point of view, passing key
> type is sufficient. Could you explain it?

Agreed.

> 6. Regarding non-intrusive version. This should be something like
>
>      CPPAN_ADAPT_STRUCT_WITH_BASE(
>          A,
>          (base_type1)(base_type2)
>          ((int, int_field_,
>              ((int_annotation, 42))
>              ((string_annotation, "Hello world"))
>          ))
>          ((std::string, string_field_,
>              ((no_serialization, std::true_type()))
>              ((no_hash, std::true_type()))
>          ))
>      )
>
> Right?

Looks good.

> One thing bother me here, is it ok to define key type in namespace scope by
> CPPAN_ADAPT_STRUCT_WITH_BASE?
>
> BOOST_FUSION_ADAPT_ASSOC_STRUCT and BOOST_FUSION_DEFINE_ASSOC_STRUCT go another way, it
> just takes structure name as parameter and left user to define key types itself. But I
> feel that when dealing with annotations this is not so convenient as inline annotations
> description in CPPAN_ADAPT_STRUCT_WITH_BASE.

I guess that's your call... unless (see below ***)

> 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,
-- 
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/