Re: [boost] [intro] Preview: Introspection library

Subject: Re: [boost] [intro] Preview: Introspection library
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-07-02 07:17:47

Zitat von David Sankel <camior_at_[hidden]>:

>> class optional{
>>  bool is_initialized;
>>  T t;
>> };
>>
> This is a good example of where tying the syntax to the semantics really
> hurts. If I want to syntactically print an instance of optional above, I
> wouldn't be able to do so because creating an introspect function would
> screw up another algorithm.

you'd have to override the print algorithm, yes. but seperating member  
definitions from semantics alone would not solve this case.
the semantics of the optional class members above can not be expressed  
with semantics tags
  the ultimate way to express semantics is to override an algorithm,  
just like the "equivalence" semantics are expressed through a  
serialize() function in Boost.Serialization.

so in a sense semantics _are_ separate from the definitions, if you  
need them to.

>
> How many semantic tags do you need to cover the semantics required for all
> algorithms that you've come up

2

> with and all the algorithms that others
> haven't come up with yet?

...

>
> I argue that a traversable concept should not mix syntax and assumed
>>> semantics, but should instead be strictly syntactic. The algorithms
>>> that are included in the library should mainly work on this level.
>>>
>>
>> that's good in theory, but how would the user specifiy semantics separate
>> from introspect()? especially with common semantics like object tracking.
>>
>
> That's an awesome question and the right one to be asking!

when data has to be associated with members, tags can be used. the  
same thing could be used for semantics:

template<class Mapping>
friend void introspect(Mapping mapping,type<A>){
   mapping
     (base_class<A_base>()                  )
     (member<A,int             ,&A::m_a>()  , a_tag())
     (member<A,float           ,&A::m_b>()  , b_tag())
     (member<A,std::vector<int>,&A::m_vec>(), vec_tag())
   ();
}

another point in code:

(A::a_tag()  ,  "xml_tag_name_for_a")
(A::b_tag()  ,  "xml_tag_name_for_b")
...

the same could be used for semantics. however, I think it is too  
verbose to be used as the default.
it could be used to specify additional semantics at most, when you  
need to specify semantics on existing types for new algorithms.