On Fri, Sep 12, 2008 at 11:18 AM, Germán Diago
<germandiago@gmail.com> 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:
- 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!
- 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.
Jeremy Pack