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

Subject: Re: [boost] [intro] Preview: Introspection library
From: David Sankel (camior_at_[hidden])
Date: 2010-07-01 12:28:19

On Wed, Jun 30, 2010 at 5:28 AM, Stefan Strasser <strasser_at_[hidden]>wrote:

> Zitat von David Sankel <camior_at_[hidden]>:
>
>> The serialization library describes its feature as a function that
>>
>> converts a supported object to a sequence of bytes and back into an
>> "equivalent structure". The meaning of "equivalent structure"
>> unfortunately isn't defined in the documentation.
>>
>> Consider the following example:
>>
>> struct Z
>> {  A * a;
>> , B b;
>> };
>>
>> If we consider syntactic equivalence, the result of serializing this
>> would be something like:
>>
>> Z{ a=0x029348af, b=B{...} }
>>
>> If we use semantic equivalence, serialization could result in any
>> number of things, including:
>>
>> Z { a=new A{...}, b=B{...} }
>>
>> or even:
>>
>> Z {}
>>
>
> as long as the semantics of a member are limited to this member and don't
> interact with other members, they can be specified in introspect(), e.g.
> ...
>

Thanks for explaining how introspect works. This confirmed my suspicion that
syntax and semantics were mixed together.

> class optional{
>  bool is_initialized;
>  T t;
> };
>
> when "is_initialized"==false, "t" doesn't matter for "equivalence".
> although it would be possible to define a new descriptor like
> "member<...>()" that covers that case, I think a class like that should not
> have an introspect() function but override the algorithms instead.

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.

How many semantic tags do you need to cover the semantics required for all
algorithms that you've come up 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!

-David

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