Re: [Boost-users] boost.extensions and boost.reflection.

Subject: Re: [Boost-users] boost.extensions and boost.reflection.
From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2008-09-12 17:03:58

German,

On Fri, Sep 12, 2008 at 11:18 AM, Germán Diago <germandiago_at_[hidden]>wrote:

> Hello. I'm implementing a property class which uses my own library
> (still in early stages) and
> I want to extend it to general reflection (not for now) and shared
> library loading.
> I found boost.extensions, which is not a boost library for now.
>
> I don't know if this is the place to ask for this, if it is not, point
> me where I could go. It's great
> to see I won't have to taje any more pain to load plugins :-).
> I would like to make a feature request. In boost.extensions, factories
> are used to construct
> types of a derived class with pointers. So, in order to register a new
> class, you have to tell which is the base
> class to the extensions system. I think there is a better way, with
> which you wouldn't need to do
> this. It is inspired in this type style of value-based type system:
>
>
> http://stlab.adobe.com/wiki/index.php/Image:2008_06_26_classes_that_work.pdf
>

>
> An object which can contain any other object (like boost::any) could
> be created. This way (this is how I do
> in my own solution) you just have to register a type without worrying
> about its base class:
>
> REGISTER_CLASS(myns, myclass)
>
> Now I can do like this:
>
> object_t myobject = introspection::create_object("myns", "myclass");
> when I want my object to become "myclass" I do:
>
> myns::myclass & refclass = get_reference<myns::myclass>(myobject);

OK, if I read this correctly, what you want is a global object containing
factories indexed by name that return a reference that can be converted back
to their correct type.

This entire functionality is provided by Boost.Reflection (with much more),
with the exception of the global registry. If you want to use a global
registry for objects, you can wrap the objects in the library and provide
your own macros. I did not want to create a dependency on Boost.Thread to
ensure thread safety for the global objects, and I didn't want to constrain
users to use the global objects.

Problems I see with your API however:

   1. This requires that the caller of get_reference know the type of the
   object being looked up. If the class is defined in a plugin, then the main
   executable may not know that type when it was compiled. The executable may
   have been compiled before the plugin was even created!
   2. What about constructors with parameters?

>
> This works fairly well, and factories go away, freeing the user from
> learning more interfaces.

Don't you still have to know the interface to myns::myclass? Besides,
interfaces, polymorphism, reusable base classes etc. are usually considered
helpful when doing object-oriented programming...

>
>  Just register your type and use it. Everything else is transparent.

Why do you need to register it if you're just going to use it using it's
standard interface?

>
> The interface is simple, no factories or anything else to handle.

Well, there need to be some sort of factories to create the objects.

> This
> can be also used from shared libraries without problems.

Besides thread-safety, RTTI, differing compiler settings, etc...

>
> At least, I think that it should be provided a way to register a
> factory of non-pointer types. In the documentation it says
> a pointer is created for the animal class, disabling this type of
> value-based registration.

A factory of non-pointer types? I'm confused - the example you describe
appears to create the objects on the heap, thus pointers are involved
somewhere. As soon as you right myns::myclass&, you are basically using a
pointer.

Could you try and describe your use cases a little bit more clearly, and
also take a look at the Extension documentation at
http://boost-extension.redshoelace.com/docs/boost/extension/index.html? Let
me apologize for the still incomplete reflection documentation.

Jeremy Pack