Re: [boost] [soc] Boost.Reflection project advances

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2007-06-08 19:05:16

Jeremy Pack said:     (by the date of Thu, 7 Jun 2007 14:14:49 -0700)

> I'd actually want to separate the "reflection" of the methods from the
> declaration of the class - the same as Boost.Extension does not
> require any plugin declarations in the class header file.

where those declarations are supposed to be placed, then?

From my point of view it's better to have a single place to update
information about a class. When method signature changes I prefer to
update just two files (.cpp & .hpp), instead of three files
(.cpp & .hpp & .hpp) (not mentioning their callers). I'll
certainly always forgot about the third file, which will lead to
compilation errors, or crashes.

But if those .hpp files are supposed to reside in the same directory
and belong to the same plugin, then the solution can make sense.
eg. car.hpp and car_reflection.hpp

However the ability of connecting both files to be a single file will
certainly be useful in some cases. Please don't disallow that. I'm
not sure which I'll really prefer, but one file less to decrease
human memory burden is very temping.

> boost::extension::reflection car_reflection<Car, std::string>("A Car!");

side note: wouldn't it be boost::reflection car_reflection<...> since
as I understand, the reflection will come out as a separate library?

A very annoying problem I encountered when implementing my own plugin
and serialization library was that templates sometimes are not
handled correctly across plugins by the compiler. I hope that you
know what I mean:

I used templates in serialization code, to determine the type of
serialized object. The template function in question was called
findType<>();

Some plugin code uses that template. The .hpp template code resides
in a serialization plugin compiled earlier.

It can happen that sometimes the compiler is not generating a code
for findType() function. It is assuming that the code for this
function is in serialization library compiled earlier. Which cannot
be true, because when serialization was being compiled the object
type wasn't known yet. The effect is that plugin is calling a
fallback findType() function, that gives an error "cannot determine
the type!".

Have you had this problem?

How do you plan to cope with a problem of templates across plugins?
It certainly exists, and honestly I don't know where it comes from,
and how to cope with it.

I'm asking about that, becuase your design decision is to put all
Reflection information inside templates, like the car_reflection<> above.

-- 
Janek Kozicki                                                         |