Hi Ulrich, Robert, and all, Ulrich, your idea seem briliant. When I was talking about "overwrit[ing] existing userData" I thought about direct pointer access. Of course, if you move userData to private, and give accessors for backward compatibility, then it's okay. That way, it would only break code of derivate classes which directly access the protected member "_userData" ; and this seems a reasonable change to me.
Finally, userData becomes a (multi)map of "Referenced"...? One point I would discuss is the duplicates handling. I personally have nothing against having duplicates (= multimap), and it may be useful to store, for instance, multiple "targets" properties on a charcater, or multiple "addresses" on a building. But this may be problematic for some usages. Another point to discuss is the kind of container: some would need fast lookup (unordered containers), some not. So what about the ability to choose that container? What do you think about: - osg::Object contains a ref_ptr<Container> (or ref_ptr<Referenced>) - Container has templated derivates, such as ContainerMap<T>, ContainerUnorderedMultimap<T>, ContainerVector<T> (which may be TemplateArray<>)... Those types are low-level, and may also be used elsewhere in OSG. - If not derived from STL clases, containers must have STL-like iterators in order to make easy to "templatize" methods - osg::Object has several methods to handle containers (set, get, delete, replace) - setProperty() would create a default container if none exists. - Of course, get/setUserData() would still be there for backward compatibility, as Ulrich proposed. Thoughts? Ideas? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Ulrich Hertlein" <[email protected]> a écrit : > On 4/02/11 3:21 , Sukender wrote: > > Ulrich is right: you could move your data as a metadata. However I > guess that we should > > not break existing code. (De)Serializers should NEVER overwrite > existing userData, they > > should only be allowed to add metadata it userData points to a meta > container. So if > > you already use "userData", then you simply won't be able to add > metadata. > > On this point is disagree: depending on the implementation of the > meta-data the user-data > can simply be stored alongside other meta-data. > > The following is from my earlier attempts to implement something like > this: > > include/osg/Object: > /** > * Sets a typed property by name. > * This convenience function will create a new Property<T> and store > * it under the given name. > */ > template <typename T> > inline void setProperty(const std::string& name, const T& value) { > if (!_properties.valid()) { > _properties = ref_ptr<PropertyMap>(new PropertyMap); > } > _properties->set(name, new Property<T>(value)); > } > > /** > * Gets a const typed property by name. > * Get property by name and cast it to const Property<T>. > * @return NULL when not found or not of the proper type, else the > const property. > */ > template <typename T> > inline const Property<T>* getProperty(const std::string& name) const > { > return dynamic_cast<const Property<T>*>(getProperty(name)); > } > > /** > * Set user data. > * Data must be subclassed from Referenced to allow reference > counting. > * If your data isn't directly subclassed from Referenced, create an > adapter object > * which points to your own object and handles the memory addressing. > */ > inline void setUserData(Referenced* obj) { > setProperty("osg.data", obj); > } > > /// Get user data. > inline Referenced* getUserData() { > return getProperty("osg.data"); > } > > /// Get const user data. > inline const Referenced* getUserData() const { > return getProperty("osg.data"); > } > > The way the user-data is serialized/deserialized doesn't need to > change. > > Cheers, > /ulrich > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
