Christian Wach <[EMAIL PROTECTED]> wrote
> Subject: Re: <lingo-l> OOP and ancestor access
>
> on 14/8/01 2:30 am, Al Hospers wrote:
>
> > 1 - instantiation: setup initial property values
> >
> > 2 - monitorPlaybackStatus: is it playing, stopped, paused
> >
> > 3 - getCurrentPosition: what is the current position of the movie
> >
> > 4 - play: start playing at the current location
> >
> > 5 - stop: stop playback & reset to start
> >
> > 6 - pause: pause playback at current location
> >
> > 7 - rewindToStart: reset the current time to the beginning
> >
> > 8 - jumpToPosition: jump to an arbitrary position in the movie
> >
> > 9 - fastForward: play the movie at a fast rate
> >
> > 10 - rewind: play the movie backwards at a fast rate
> >
> > 11 - playDone: handler to execute when the movie is finished
> >
> > 12 - killObject: cleanup the object when you are done with it
Item 1 - instantiation would probably (and most importantly) cache values
such as movie duration, so we might need to have a special handler which
does this more than once for those situations where we swap the member.
Special handler? Aha. Warning bells ring in my head. (See below)
I have problems with items 2 and 3. These should either be public (in which
case, just use the standard quicktime sprite access calls:
sprite(s).movierate and so on), or private.
An object who wants this data should have a good reason (a slider, perhaps).
Like I said, the QT wrapper might offer a callback option.
The rest is good.
> I'd suggest
>
> 13 - switchFile: switch the member.filename with the no-flash workaround
When we get into member territory, I get a feeling we might need another
object in there, particularly for swapping filenames. It depends how central
that functionality is supposed to be of course. If it was supposed to
include (say) a playlist functionality, I would argue for a seperate object,
dedicated to handling member swapping. This might also inform the QT wrapper
object or slider controller of the new duration (etc).
> I was thinking about the slider/qt thing last night, and realised that QT
> has a slider object as a child (the 'show controller' button) whereas I had
> been thinking in terms of the inheritance working the other way around...
Well what about behaviors? Do they inherit the sprite, or is it the other
way round?
> Anyway, I ended up unable to decide how to put the 'code family tree'
> together as a result... which should inherit which? Is this a common
> problem? <g>
YES!
I've sweated over details like that for hours. When I get to a solution, I'm
always amazed how simple it seems, and how long it eluded me. Building an
optimal inheritance hierarchy is no mean task, making great demands on
creativity as well as logic. Unfortunately, the solutions are often so
banale, that no-one can appreciate the effort. We're so misunderstood! (But
the pay is ok).
The good thing is that if you encapsulate properly, you can rearrange an
inheritance chain as you go. It's not something you'd want to do in the late
phases of a project though.
--
_____________
Brennan
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
