Hi Chris, On Mon, Nov 30, 2009 at 5:59 PM, Chris 'Xenon' Hanson <xe...@alphapixel.com> wrote: > Robert Osfield wrote: > Isn't this breaking all existing code that uses UserData/Description though?
No, no user code need be change, you can hide all the internal implementation details via the methods that access getUserData and getDescriptions(). What would change as far as the user is concerned is that we add extra methods that access other data elements in the CompositeUserData strucutre. > 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? The existing style UserData and Descriptions could be stored in the exactly the same way as they are now, only shifted into the CompositeUserData structure. The additional new key based stored could be added alongside these. > 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? 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. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
