Mark made great explanation of an OOP structure.
However, reading it only makes me nod, it doesn't make me shake my
head, or feel dizzy, and that was sort of my expectation, from all
the fuzz.
Maybe there's an important mental difference in calling a method
"handle" something, rather than "set", but it boils down to the same,
if you tell the movie to go to 60%, it does so, or it's not a
reliable object.
You have effectively "set" a state in the other object, and you did
so, by supplying flat data.
I still think, that there is some wisdom in the concepts about
sending objects over a network, and I'd like to use that with the
MultiUser Xtra. But somehow, we're already doing that when we use
Shockwave... we send and object - the movie, and it displays itself,
in the "window" provided by the plugin.
I think that is about actually moving your codeBase along with your
data, rather than flattening the data, and that can happen at
different levels, ranging from sending "media" data over a MU
channel, to send the complete OS to a NC, which then displays "the
object" into its "window"; the Monitor.
I think the only practical question left open by Mark's explanation,
is how the components of the "cluster", actually identifies each
other in the score.
Don't use globals, because then you can only have one cluster in the
runtime engine.
Usually I would use sendAllSprites, and I would let the "central
manager" object broadcast the "collect" message with a "collectList"
parameter. This would happen at prepareFrame, so that the manager can
be in a lower channel, and still find the other behaviors. Maybe the
propList approach is too brute-force for this purist exercise, and
maybe the manager should broadcast a message
"handleTheFactThatImHereAndIWouldLikeToTakeChargeOfAnyoneSoInclinedAccordingToMyIdentification".
Then the components could themselves decide to reply with a
"handleMe" message, and so register themselves for event messages
from the manager, and storing the reference to the manager, to use
when they're later fondled by the mouseHandler. This is a system with
mutual references, which should cleared when the cluster dissolves.
The most obvious way to setup the "cluster ID", would be by way of a
GPDL in the behaviors.
If the "slider" itself comprises a "sub-cluster" of base, buttons and
thumbs then that cluster would also have to be initialized before
getting "dodgeThis'" events from the manager, the subManager could
initialize on the "gather" message from the überManager, or on
prepareFrame, whichever comes first.
Nothing revolutionary, just plain exploitation of Directors framework... ;-)
Do you see a way to clean that up, according to the "antiAccessor declaration"?
But...
<confusion>
There's the situation where the slider moves the qtMovie... err,
politely informs the qtMovie to get its butt over to another
position. Then the manager broadcasts this event to all the
components, including the one who inflicted the event. Should this
object now readjust its state, or should it ignore the message, or
should it wait for the event to "bounce" in the manager, and then
adjust?
I think I like the "ignore" model most, but maybe that's just from an
optimization viewpoint.
If the component speaking to the manager provides it's own reference,
then the event broadcasted could also bear the component reference,
but this is where the interface becomes sort of "proprietary"...
And what if the message is asynchronously handled by the manager?
When should it broadcast the event, and what data should it actually
provide? Remember, we're not allowed to let the components "ask" for
the "state" relevant to them.
Hey, I'm being scrubbed by this guy and now my rate and time is this,
or maybe it was my soundLevel that was adjusted, so here it goes
too...
Should there be only one "somethingHappened" message loaded with
data, which would in fact occur at every iteration of the system,
when the movie is playing, or should there be specific messages for
specific events, and then why would the slider have to understand a
"soundLevelEvent" message?
Should the components register for only specific messages?
Or should the components register in prefab "slots"
Or should we just rely on Lingo's ability to "call" nonexistent
methods in a list of objects?
But where is the pure OOP in that? shouting gibberish at innocent
bystanders! ;-)
Suddenly it seems so cloudy again... can you wipe away the clouds?
Why don't we just allow for the manager to comprise a "system" with
data-services *accessible* by those who know its "abilities"?
Or a complete "custom" system where a qtObject knows that when it
stops, it should update the "stop" button, to indicate the new state
of "unstoppability".
Hopefully I just lost my way somewhere in the bush.
Regards, Jakob
</confusion>
[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!]
