Michael Bayne
2c27824718
the way I was doing inheritance between the display and editable scene implementations was not copacetic. The new method (which is for every editable scene impl to delegate to a display scene impl so that regardless of how far along you are on the inheritance chain, there are only ever two actual objects, the display impl and the editable impl) is somewhat cleaner, but makes it clear that no method can work as nicely as it would were we to have mutliple inheritance. The basic problem is that the editable versions of the scenes have to be able to manipulate the instance variables in the display versions of the scenes because they have to keep them up to date so that they are displaying the right thing. As the editable versions are in different packages, they don't have access to the display instance variables, so the display versions simply have to make available enough "editable" functionality to allow the editable versions to get their job done. It's more coupling that I'd like, but at least it's only between the display and editable versions across the inheritance hierarchy rather than down the hierarchy. Blah. git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@745 542714f4-19e9-0310-aa3c-eee0fc999fb1