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); This works fairly well, and factories go away, freeing the user from learning more interfaces. Just register your type and use it. Everything else is transparent. The interface is simple, no factories or anything else to handle. This can be also used from shared libraries without problems. 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.
German, 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: 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
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 __________
There is a way to use value-based types (with non-pointers) even from shared libraries. I think you didn't read the paper I linked. It's ok to have factories with types which are pointers to base classes. But I'd like to be able to use a factories to register types with no pointer in its creation so that I can use non-pointer factories with my own non-intrusive interfaces. I know it sounds weird. If you want to understand why I want this, take a look at the paper I linked and these ones: run-time concepts: http://www.emarcus.org/papers/oops2008-marcus.pdf mixing objects and generic programming: http://www.emarcus.org/papers/MPOOL2007-marcus.pdf Pseudo-code. With this technique your examples could become (but they don't need to): //This is the object that takes the role of interface class any_animal { void get_name(); ... }; factory <any_animal, int> ... //This factory should be of non-pointers //Note: no inheritance. class dog { void get_name(); }; class cat { void get_name(); } Now I could use it like this: //Dog is contained inside this object any_animal a = create("dog"); any_animal b = create("cat"); //Calls dog::get_name a.get_name(); //Calls cat::get_name b.get_name(); This way I can adapt external code to be used with my library (no need an animal to inherit from anywhere, just implement the functions). I want to use boost.extensions and boost.reflection, but I need a way to create value-based factories so that I can enable non-intrusive interface classes like the one above. It's the only thing I need. With the example above the castings go away. The class any_animal holds the real objects (dog, cat...) and is used as an interface with value-based types. And you can use naturally these types with stl algorithms. It's similar to what boost.function does with any kind of callable type. _____________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sorry for my mistakes in the code. I wrote very quickly. Anyway, I think the basic idea is understood. Please do take a look at the papers, I think the use cases can be understood.
_____________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
German, On Sat, Sep 13, 2008 at 1:13 AM, Germán Diago <germandiago@gmail.com> wrote:
Sorry for my mistakes in the code. I wrote very quickly. Anyway, I think the basic idea is understood. Please do take a look at the papers, I think the use cases can be understood.
I won't have time to dig into the second and third papers today (though I have read the second one recently, and you'll notice that I use the same types of techniques in the parameter_map class), but I do have a couple of questions: 1. Could you send me the corrected version of your code? If I match the API for the "mistakes in the code", you won't get what you want :) It's not entirely clear which parts are mistakes and which are on purpose. 2. What API would you prefer for exporting such classes? 3. What are YOUR specific use cases? I know what the use cases of the authors are - but if it is those use cases that you need, you ought to use the code that they have written instead. Much of it is, I believe, open source. What you propose seems to be a special case of the Adapter Pattern. In that case, perhaps it could be implemented something like the code I put into: http://svn.boost.org/trac/boost/browser/sandbox/libs/extension/examples/valu... I threw this code together in less than ten minutes, meaning it doesn't support multi-parameter constructors and a few related things. The basic idea should be there though. Is this the type of thing you are looking for? The declaration of the various boilerplate classes could certainly be shortened by using macros, but I'm not sure it's worth putting in as actual library functionality since many users might need highly specialized versions of the adapters (and because macros are ugly, and I need a really good reason to use them). Jeremy Pack
participants (2)
-
Germán Diago -
Jeremy Pack