Hi Robert, On Tue, Dec 8, 2009 at 9:09 PM, Robert Milharcic <[email protected]> wrote: > This is great, thank you! To be honest, my suggestion was inspired by the > GraphicsContext::ResizedCallback and that is why I choose to propose callback > over making osg::Image methods polymorphic. I thought callbacks are osg way > to solve such problems...
When and where to use virtual functions and/or callbacks is not straightforward, one has to use good taste and a few different measures to restrain yourself - such as the "minimal and complete" phrase. I roughly follow the below approach: First up I typically write methods that should never over-ridden as inline, these tend to be along the lines of the template methods design pattern, or just inline them for speed in the case of accessing member variables. Next level up is a standard method that is used to implement general functionality of the class, but doesn't need extending and shouldn't be changed, so no need for a virtual function or callback. Next level up is virtual functions that allow for subclasses to override general functionality. Next level up is adding a callback to override an individual virtual function, rather than require sub-classing a whole class - this is appropriate when you the types of behaviour you want to override is very distinct and may happen in separate parts of your application, and where you want to change the behavior of say all subclasses of osg::Group's, or where the object is already constructed and you want to such as ones loaded from a plugin and is out of your control. These callbacks that override virtual functions use an inline method + virtual method template method design pattern approach where you have the public method that gets called by the app as an inline - this checks for the presence of the callback and calls it if there is one, else calls the virtual functionImplementation() method. Always temper the above with "minimal and complete", each level up has to be justified for the extra bloat that it could introduce, the extra maintenance burden of handling more code and the more impact it'll have on performance. Have a look through the OSG and see where you can spot these different approaches and work out the decisions behind them - this will give you and idea of when and where I'm likely to give a thumbs up and down to a change. >BTW, I was also playing with more involved solutions, like camera ability to >attach custom object, but such approach would probably never be accepted. >Anyway, I'm happy with the decision you made. Thanks again. Might I suggest posting a "how do I attach a custom object to a Camera" question to osg-users, as there is good chance what you want to do is already solvable without changes to the core. One can't make any judgment on this without first knowing what problem you are trying to tackle. Cheers, Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
