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 |