Robert Osfield wrote: > Description kinda bloat osg::Node already, I would like to reduce this > bloat and stream line the base classes even more ;-) > I would also like generalize UserData but... not use any more than the > present pointer that we already have in place, don't forget we need to > aim for less bloat not more... > My thought was that you could possibly create a CompositeUserData or > similar class that you attach as the via the present _userData pointer > when you need the extra services such as description, user data > accessed via int/string descriptors etc. Such as scheme could be > hidden by accessors methods in the base class that only even attach > the full blow CompositeUserData when actual data is attached to the > object.
Isn't this breaking all existing code that uses UserData/Description though? Let me toss back what I think you're proposing. We create a new class called something like UserPropertySet (this is my name for what you called CompositeUserData). This thing has a container for storing some collection of heterogeneous things: strings, floats, maybe even ref_ptrs to things?(I don't know how the ref_ptr aspect would work, but it seems people wish to associate all sorts of things with their Nodes.) The container uses a key/value map, so you can ask for a thing by key. To support the existing Description API, we use string-type things in the container, with a unique-namespace key name like "osg internal Description" or something. We either permit multiple items with the same key string (so we can have multiple Description entries), or we have to name each Description entry uniquely "osg internal Description #1" "osg internal Description #245", ... and then find a way to query for all keys that have a unique prefix "osg internal Description #". I'm just brainstorming here, so don't take offense at my potential ignorance. it odes sound like a lot of us need to hang diverse data off our Nodes and have been constrained by this. Comments? What kind of container can do this for us, and sort out the diverse types we might cram in there, and find entities by their key name? > Robert. -- 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org