Hi Paul, On Fri, Feb 29, 2008 at 9:22 PM, Paul Martz <[EMAIL PROTECTED]> wrote: > Maybe I'm not making myself clear. > > What you say is true if and only if the only code that uses the old callback > is your application. If core OSG is using the old interface callback, and an > application overrides the new callback and doesn't call the old callback, > then the piece of core OSG using the old callback will break. > > This is the case with OcclusionQueryNode. It is currently coded to use the > old callback. If an app overrides the new callback and doesn't call the old > callback, and has OcclusionQueryNode in its scene graph, the OQN won't be > able to retrieve results, and will stop functioning.
This is pretty torturous, one would have to override the OcclusionQueryNode's callback and ignore the fact that its implementing the Camera& version and not doing anything to call it. If it then stops functioning well the developer should be able to add 1+1 and get two and fix his code. > > > Currently, OcclusionQueryNode uses the old interface to retrieve > > > query results. > > > > > > Could you possibly rearchitect this change so that we have some > > > assurance that the old interface will continue to get called? > > > Alternately, you could modify OcclusionQueryNode to use > > the new callback interface. > > > > I don't see a strong need to remove the old method right now, > > its slightly less minimal and perhaps a potentially little > > confusing but code wise its not unsafe. > > I'm not asking for the old method to be removed. I'd just like to see this > change modified to ensure that the old callback always gets executed, so > that OcclusionQueryNode doesn't break if an app overrides the new callback > but fails to call the old callback. How might one ensure that the old callback always gets executed?? Would this not add extra complexity, increase the likelyhood of bugs and general confusion when users review the code? Also, would this not always prevent the user of controlling his application, for instance what if he didn't always want to call the base classes override of the Camera& operator. Unless of course you then added a further extra level of complexity into the callback so the user could then control whether the automatic call of both methods happens. Even then what happens if the user ways a pre and post operation of this call. It would seem to a good case of digging oneself in an ever deeping pit of complexity whilst providing less actual functionality. Its surprisingly flexible just to leave it as a nested call, and leave it up to the user to control whether he wants to call the nested Camera& operator. I use the method of inner calls all over the OSG, such as NodeVisitor and the how callbacks are nested within this. Its a scheme that allows one to fully control traversal without the need for extra layers of complexity in the API, and its naturally thread safe. It might be a very simply coding trick, but its very powerful. The only actual changes that seem sensible to me are to either formally deprecate the inner function and put warnings when its called for the next release, then to remove the inner Camera& operator after this, or just to stick with what I've done. Perhaps one could just stick ones neck out and remove the inner call completely and just give a warning that the old version is no longer available called and that developers should adjust their code. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
