Re: [boost] [soc] Boost.extension/reflection project advances

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-06-06 14:25:20

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_at_[hidden]> 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
>