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

Subject: Re: [boost] [intro] Preview: Introspection library
From: David Sankel (camior_at_[hidden])
Date: 2010-06-29 22:49:29

On Tue, Jun 29, 2010 at 6:21 PM, Stefan Strasser <strasser_at_[hidden]> wrote:
> Zitat von David Sankel <camior_at_[hidden]>:
>
>> On Mon, Jun 28, 2010 at 8:00 AM, Stefan Strasser <strasser_at_[hidden]>
>> wrote:
>>>
>>> I'd be interested in comments on an introspection library I've been
>>> developing.
>>
>> You may find paper "Scrap++: Scrap Your Boilerplate in C++"[1] to be
>> interesting for ideas. One thing that confuses me about your library
>
> thanks. (direct link:
> http://sms.cs.chalmers.se/publications/papers/2006-WGP.pdf )
>
> do I understand the paper correctly that you can't traverse two instances of
> a type at the same time?

I'm not too familiar with that paper, but the SYB approach in general
covers this use case, coined twin traversal.

> that's a central part to my approach. the (const) traversal of a single
> instance could have been accomplished with the Serializable concept, but
> algorithms like copying or comparing objects could only be implemented very
> inefficiently by serialization.

Semantics deal with the meaning of something and syntax deals with the
internal structure of the representation.

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 {}

It depends on what the meaning of a Z is.

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.

>> is I don't know whether the reflections are semantic or syntactic. I
>> do think a clear separation of syntax and semantics is important to
>> writing clear code. Perhaps you can show what a shared_ptr
>> "implementation of the concept" looks like?
>
> it depends on the shared_ptr implementation if you'd actually implement
> introspect() for shared_ptr, but I guess you mean supporting shared_ptr in a
> specific algorithm.
> apply_recursive, which seems to be comparable to scrap++:

All the algorithms included in the library that work on a semantic
level (like equality, serialization, etc.), might have a default
implementation that works only on the syntax (although this is scary),
but ought to at least be overridable for any structure where the
syntax doesn't match the semantics. For example, consider the function
inc that increments an "int" in-place.

template<typename F, typename T>
T applyToAll( F f, T t );

struct X
{
  int a; //Invariant: a is always 0;
};

struct Y
{ //... Some member variable has an X in its internal structure.
};

Y y0 (...);
Y y1 = applyToAll( inc, y ); //y1 invariant broke!

I'd argue that fixing this problem should _not_ involve changing X's
introspect function and thus mixing syntax and semantics.

>> Fusion's adapters, which are purely syntactic, are perfect for what
>> I've needed so far. Syntactically speaking, are you adding anything
>> besides data inheritance?
>
> I'm not familiar with that distinction wrt reflection.

Hope the above helps.

David

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