Ulrich Hertlein wrote: > This sounds like a good solution, it keeps API compatibility but only > stores one object instead of _userData/_descriptions in every > Object/Node created.
This sounds good. I had forgotten that access to UserData was only through the set/get API. Perfect. > So many birds with one stone :-) Ulrich, do you have a sense of how this should be done? I don't know if I have a lot of time to work on it right now (starting a new project already), but I can try to help. I could sketch out some architecture and maybe some prototypes in my spare time. Robert said: > The key to making the transition seamlessly would be to not have one > data structure in the new container but several for the different > purposes. Since the data structure is only ever created when needed > the fact that it has some extra members that aren't used in all cases > won't cause too my in memory bloat. I'm sort of thinking out loud, on (e-)paper here, so feel free to shoot holes in this design: We design a class called something like CompositeUserData (I dislike this name, and prefer something like UserPropertiesCollection). It is allocated only when requested by one of the UserData/Description/Property APIs. In it is simply a container (STL map?) of some new class UserProperty. UserProperty could either be an abstract base class with a derived implementation for each property type (UserData pointer, Description string, float, etc). Or, it could be a concrete implementation itself of a single class with a member or members that can store any of the possible data types (I think Visual Basic had something called a Variant http://en.wikipedia.org/wiki/Variant_type ). I don't have any preference either way, so perhaps others who have a dog in this race might comment on their feelings for the architecture. A new API can be added like setUserProperty("keyname", SOME_TYPE, value); and value = getUserProperty("keyname", SOME_TYPE); Not sure if SOME_TYPE is a string or an enum. We can prevent key name collisions between types, and avoid considering the whole issue of using getUserProperty with the wrong TYPE by name-manging the type into the actual keyname used to store the property. So you could set a STRING of keyname "foo" and a FLOAT of keyname "foo" and they would co-exist because they're actually stored as fooSTRING and fooFLOAT. In the same way, we can implement the existing UserData and Description APIs with specialized types like "DESC" and "UDATA", so that they won't collide with the generalized API. The existing Description API seems to respect the order of the Descriptions and existing code might rely on that, so they'd probably be stored with key names like DESC00001, DESC00002, etc to preserve the order. Comments heartily requested. > Cheers, > /ulrich -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
