Hi Janek! I can answer a few of these:
1. do you plan to use (not yet accepted) Boost.UUID to uniquely identify classes for the class factory?
The library allows you to define an arbitrary type identification facility. Check out the typeinfo header. It uses RTTI names by default - but you can identify your constructors by version number or any other mechanism. I'd say that Boost.UUID would be a good fit. We'll try to add an automatic way of using it (but not require it). For instance, the factory_map class is actually just a typedef: typedef basic_factory_map<default_type_info> factory_map; You could instead define your own, by following the conventions in the typeinfo header. This will be detailed in an example. Then you could do: typedef basic_factory_map<boost_uuid_type_info> uuid_factory_map; And use it just like a factory_map.
2. how else do you identify them if not with UUID ?
RTTI. Some platforms (OS X) actually work fine just using the type_info reference returned by typeid - other platforms (Windows, for instance) only work with the full typeid(x).name(). But see above for other options.
3. I remember that Boost.Serialization is also using its own home-brewn GUID called extended_type_info. It would be really nice if both libraries (serizalization and extension) used the incoming UUID library, instead of some home-brewn solutions. Any comments on that?
I agree. We ought to standardize it. For now though, we'll probably include a header to use extended_type_info, a header to use uuid, and leave the default as RTTI.
4. Do you plan some integration with serialization library? (serialization after all, needs to create classes during the deserialziation process, it's a crucial part of this process, in fact).
I, personally, hope so. But it is not planned for SoC currently. If someone would like to volunteer ...
5. does your library work without bjam? (I remember that Jeremy Pack configured Jamfile to use *.extension). I'm particularly concerned with that, because I don't want to change the build system in my project ;)
Yep - it works fine without bjam. The basic functionality currently works without Boost at all (though advanced functionality requires it - as do the tests). You don't have to rename the files. You can just use *.so, *.dll or whatever. I just used a different extension for ease of cross-platform use.
6. do you have a simple example, with a different build system? I'd prefer make (ie. makefile), as it is simplest to adapt to any other build system that I know.
I believe it should be quite straightforward. Just put the boost/extension directory in the system include path. Then use it in your project. You can use the functionality you'll need with only the STL. Only some of the "convenience" functions depend on Boost. If you don't include those headers, you won't need Boost installed (though why you wouldn't want to use the rest of Boost if you were already using this library...).
7. can you explain shortly what Reflection is? Or some URL with explanation, please.
I think of reflection as runtime type information about the methods of a class for which you do not have access to any of its base classes. As such, there are a lot of directions one could go with it - I'm not sure which direction Mariano will choose. Some of these directions are really hard in C++. I think we'll be discussing that a lot in about three weeks - and will want lots of input from the community.
8. You need to record information about classes stored in plugins. Does this information include also the inheritance hierary? I mean - do you know on runtime which class derives from which one?
Yes and no. When you export a class as a plugin, you must declare which interface it is being exported as. As such, you must have a different declaration for each interface it is being exported as: current_factory_map.add<flying_car, vehicle, std::string>("A flying car exported as a vehicle"); current_factory_map.add<flying_car, car, std::string>("A flying car exported as a car"); Here, a flying car is exported first through its vehicle interface, then through its car interface. If we wanted to allow just exporting a flying_car and let it be loaded through any of it's interfaces, a whole bunch of dynamic casts could do it. I don't believe this functionality is necessary. So, the only inheritance information we know is what is explicitly declared when the class is added as a plugin. You could always use the Info template type to store information about the inheritance hierarchy, if you need that information.
I'll send a mail like this periodically (probably once a week or two) to let you know the advances.
It would make things easier for me (and others!), if in each periodical post from you, you will give an URL (or svn command with svn:// addres) to download your library, and maybe an URL to documentation (at its current stage, of course - I absolutely don't expect to see finished documentation on start!).
The best place to get it is still the sandbox. We'll put periodic releases in there zipped. The last release is already out of date though. (I put it up a week ago, but Mariano added some new good examples). As such, I recommend pulling down the sandbox with SVN and syncing it once in a while. If you just want to browse the latest release though, check out this URL: http://svn.boost.org/trac/boost/browser/sandbox/libs/extension Jeremy On 6/6/07, Janek Kozicki <janek_listy@wp.pl> wrote:
Mariano Gabriel Consoni said: (by the date of Wed, 06 Jun 2007 14:07:36 -0300)
As some of you may know, I'm working on a SoC project called "Boost.extensions and reflection".
great to hear from you! :-)
I still didn't download your library to test it locally. I'll do it not later than next week, I'm sure of that.
Some questions I have:
1. do you plan to use (not yet accepted) Boost.UUID to uniquely identify classes for the class factory?
2. how else do you identify them if not with UUID ?
3. I remember that Boost.Serialization is also using its own home-brewn GUID called extended_type_info. It would be really nice if both libraries (serizalization and extension) used the incoming UUID library, instead of some home-brewn solutions. Any comments on that?
4. Do you plan some integration with serialization library? (serialization after all, needs to create classes during the deserialziation process, it's a crucial part of this process, in fact).
5. does your library work without bjam? (I remember that Jeremy Pack configured Jamfile to use *.extension). I'm particularly concerned with that, because I don't want to change the build system in my project ;)
6. do you have a simple example, with a different build system? I'd prefer make (ie. makefile), as it is simplest to adapt to any other build system that I know.
7. can you explain shortly what Reflection is? Or some URL with explanation, please.
8. You need to record information about classes stored in plugins. Does this information include also the inheritance hierary? I mean - do you know on runtime which class derives from which one?
I'll send a mail like this periodically (probably once a week or two) to let you know the advances.
It would make things easier for me (and others!), if in each periodical post from you, you will give an URL (or svn command with svn:// addres) to download your library, and maybe an URL to documentation (at its current stage, of course - I absolutely don't expect to see finished documentation on start!).
-- Janek Kozicki | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost