Hi DJ,
You're welcome! And thank you for exposing your thoughts.
Well, you're right, "the problem has always been there". And of course,
removing the container will remove userData and descriptionList. However I
think that a developer removing the container MUST know what (s)he's doing. You
must not blindly remove it hoping userData and descriptionList will be kept.
Maybe this would require additional documentation? And maybe we could provide a
function to "clear all but things for backward compatibility"? For instance:
/// Empties a container from all but userData and descriptionList, for
backward-compatibility.
void clearValuesButUserDataAndDescriptionList(osg::ValueContainer & vc)
{
Iterate over values
if value isn't userData or descriptionList, remove it
}
/// Removes the container of an object and replaces it with a default one, and
also keeps userData and descriptionList, for backward-compatibility.
void removeContainerButKeepUserDataAndDescriptionList(osg::Object & o)
{
if (o has no userData nor descriptionList) { Remove ValueContainer from
'o'; return; }
Create a new (default) container
Copy user userData pointer and/or descriptionList from old container to the
new one
Add new container to 'o', replacing the old one
}
But clearly your project may benefit from being "ported" to the new metadata
system, as our project is currently being. You'll not suddenly gain astonishing
features, but at least you'll have something which will not interfere with
existing 3rd-party meta and/or userData and/or descriptionList.
Maybe we should put this discussion (once finished and summarized) in a v6 of
the document?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
----- "D.J. Caldwell" <dlcaldwel...@gmail.com> a écrit :
> Hi Gregoire, Sukender, and everyone,
>
> While writing this email, I have come to the conclusion that I/we do
> not really have anything (more) to be concerned about with tying user
> data and description list to the meta-data system. If you are
> interested in some of the concerns I already had, and that were
> further clarified while reviewing the proposed meta-data system, read
> on. I appreciate the responses I have received thus far. Again, thanks
> for all the hard work! :-)
>
> ...here is what I was thinking...
>
> My concern is not so much that the underlying structure will be
> unavailable, per se. It is that userData and descriptionList will now
> be tied to the meta-data system, with no built in alternatives. With
> the proposed implementation, replacing an existing meta-data container
> would effectively "clear" any existing userData or descriptionList.
> Further, if the special hooks for exotic types are part of the
> container, and that container is not written to handle generic data
> such as userData and descriptionList, use of userData/descriptionList
> may cause problems.
>
> Really, I am just trying to make sure I/we understand all the
> implications of tying userData, descriptionList, and meta-data
> together in the same core feature.
>
> Here is one problem scenario that I have some concern about:
>
> [code]
>
> // load some data
> osg::Node* p = osgDB::readNodeFile ( ... );
>
> ...
>
> p->addDescription ( ... );
>
> ...
>
> // if the following "third party" function calls setValueContainer,
> // this destroys any existing userData and/or descriptionList
> thirdParty::doSomeWork ( p );
>
>
> [/code]
>
> In my project, we have been using descriptionList as a work-around to
> userData and the fact that each osg::Node is restricted to not more
> than one attached instance of userData. I did not want to interfere
> with any existing userData generated by geometry and scene files, so I
> used descriptionList to store our runtime data, because
> descriptionList appears to have no explicit restrictions beyond that
> of a std::vector. If a "third party function" happens to cause the
> description list to be cleared after we have added some data to it, we
> would lose the data we need to do some of our runtime work.
>
> In reality, the proposed meta-data system does not cause the above
> problem scenario; the problem has always been there (the third part
> function could have directly called setDescriptions). However, this is
> one more way to "clear" the description list.
>
> I suppose, in the end, there really is no need for my concern. You
> propose (or I have inferred) a required interface with specific
> guaranteed behavior for writing custom containers; if container
> providers follow the rules, userData and descriptionList (or whatever
> a client may want to use) will still be supported. As long as no one
> takes the opportunity to replace an existing meta-data container
> without documenting that this is what they are doing, we should be
> fine.
>
> I will review version 5 of your document, and I will give myself some
> more time to digest what you have written. I already like what I have
> seen, and the more that I think about it, the better understanding I
> have of the developing situation.
>
> Thanks, again...
>
> D.J.
>
>
> On Mon, May 2, 2011 at 10:05 AM, Sukender < suky0...@free.fr > wrote:
>
>
> Hi D.J., hi all,
>
> Here is the v5 update! Not a huge thing but we modified it according
> to our experiments. Check out the "[v5]" tags in the document.
>
> @DJ: Well, as Gregroire said, the methods are always here to access
> userData and desriptionList, but you cannot access the members
> directly, as they disapeared. In core OSG, we spotted that there were
> very few direct accesses. Do you fear this would not be the same for
> OSG users?
>
> @Gregoire: On the right path you are, padawan! ;)
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
> ----- "Gregoire Tarizzo" < gregoire.tari...@virtuelcity.com > a écrit
> :
>
> > Hi D.J. , hi all,
> >
> > First, thanks a lot to all, for your feedback and ideas. I’ve been
> > following with a lot of interest your ideas and propositions on this
> > topic and it helped us a lot. The v5 of the documentation will be
> out
> > soon (likely monday), with more detailed information and the latest
> > changes we made in our implementation.
> >
> >
> > @D.J. About the deprecation of _userData and _descriptions :
> > Well yes, this behaviour is intended. One of the objectives of this
> > meta-data system was to replace _userData and _descriptions from the
> > object and node and by doing so, make it a few bytes lighter when
> not
> > using any of those, while providing a tool able to handle multiple
> > values from multiple types.
> > Moreover _userData and _descriptions may be removed, but it doesn’t
> > mean that all the _userData and _descriptions methods won’t work
> > anymore. We reforged them so that they use the new metadata system.
> So
> > hopefully it won’t change anything for the user. One of our first
> > issues was the “protected” access to _userData, meaning we can’t
> reach
> > the 100% backward compatibility if we delete _userData because of
> the
> > possibility of a direct access to this member w/ using the getter.
> > In the end, we thought that the side effect is not major enough, and
> > easy to deal with (juste replace the direct _userData accesses in
> > Object derived classes by the getUserData() method, and it works
> > fine).
> >
> >
> > 1st post on this mailing list/forum, yay. \o/
> > Regards,
> > _______________________________________________
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
