One approach would be to do what Max suggested the other day, make <view> less monolithic, moving sets of features to mixins or to subclasses, e.g., play on view really only makes sense for a view with a multi-frame resource, so maybe that should really be <multiframe> or something, instead of just <view>.
Back in the old days, we packed everything into view because subclassing resulted in a lot of overhead. This is certainly no longer the case in swf10, and much less do in DHTML. You might even see a performance improvement by trimming out less-frequently used features into mixins or subclasses. Obviously this would require some design work, but it should be fairly safe to take orthogonal features out into mixins. (This is why Traits are popular -- they force orthogonality.) On 2011-01-05, at 23:50, Henry Minsky wrote: > The W3C HTML5 media playback API specifies a "play" method, which takes no > args. There's also a "pause()" and "load()" method. > > I'd like to implement the HTML5 media class to have a play() method, but > we've already got one on LzView. > > I can override the "play()" method, although when we have a swf version of > the class, we will have to match the existing arguments type signature in > order to make the Flex compiler happy. It's not out of the question to > override it, since all of the LzView.play() method args have default > values, so calling it play() no args is OK. > > If I override play() on this class, I don't *think* it will cause anything > to break, assuming that nobody tries to give it a resource and then expects > to be > able to use the LzView playback API on that. > > I just feel a little cheesy about doing this, even though I really want to > have as compatible an API as possible. I could name it something else, like > "start()" or something... > > > > > -- > Henry Minsky > Software Architect > [email protected]
