Well, I've finally done some testing and here's what I've learned.
ancestorScript
property pbState
property pbAncestorState
attachedScript
property ancestor
property pbState -- not defined as such, but acquired via ancestor's GPDL
property pbAttachedState
The attachedScript is attached to a sprite on stage. It sets the
ancestorScript as it's ancestor. I used the ancestor's GPDL for pbState,
and also copied the pbState property to the ancestor on beginSprite, so in
effect I have 4 properties (and the ancestor property): ancestor.pbState,
ancestor.pbAncestorState in the ancestor, and me.pbState,
me.pbAttachedState in the attached (as referenced from the attachedScript).
I attached attachedScript to a set of N sprites and then used
SendAllSprites(#TimeTrial, 10000) to call it and get N results. and
increased 10000 to 100000, etc.
Doing tests where a script called just it's own property as either property
or me.property resulted in no significant difference (often the same
milisecond results or which one was faster varied from sprite to sprite, so
no difference).
One thing which may change my approach came out during the testing of
setting the pbState in the ancestor: If "on TimeTrial me, iterations" is
ONLY in the ancestor, then the "me" that TimeTrial in AncestorScript gets
is the AttachedScript object. But if AttachedScript has "on TimeTrial me,
iterations" and you call "TimeTrials(ancestor, iterations)" to pass the
event to the ancestor as well as do something before or after the call in
AttachedScript, then the TimeTrial handler gets the AncestorScript
object. So, me.property will point to something different depending on
whether the AttachedScript has that handler or not. EG
--ancestorScript
on mouseDown me
put me
end
on mouseUp me
put me
end
--attachedScript
on mouseUp me
mouseUp(ancestor)
put me
end
mouseDown will return <offspring "AttachedScript" 5 4ed6f8> but mouseUp
will return <offspring "AncestorScript" 5 4bbcd4> then <offspring
"AttachedScript" 5 4ed6f8>.
Well, of course. But because of this, I wouldn't want to just start
calling every property me.property in a script if it maybe someday might
end up being used as an ancestor script.
When I ran the test on changing the pbState property a bunch of times from
the ancestor, I found that the ancestor changes it's own property pbState
in 75% of the time it took for it to change that property in the
attachedScript. (pbState = NOT(pbState) vs. me.pbState =
NOT(me.pbState) where me = attachedScript for a handler in the
ancestorScript). And this is probably good, since it technically is
changing someone elses properties, not it's own (bad OOP).
So, If I'm going to re-use a behavior as the ancestor of another behavior,
the ancestor script probably shouldn't reference me.property OR the
adopting behavior needs to have handlers for all of the ancestor's
handlers, even if they only call ThisHandler(ancestor) in them. Since
I'm trying to make things as clear as possible, a bunch of handlers which
only pass doesn't seem good.
--Strange behavior noticed--
When I have no mouse---- handlers in the attached script, I don't get any
messages to the mouse---- handlers in the ancestor script. I even made a
separate movie to test, and if the attached script has a mouseUp/Down, then
the ancestor gets mouseUp, mouseDown, and mouseUpOutside messages. Adding
just mouseEnter then also gives me mouseEnter/mouseLeave messages. So in
order for my toggle button script used as an ascestor to get these mouse
messages, I need at least a mouseDown and a mouseEnter in it which just
call the same thing in the ancestor.
Anyway, for myself, a script which uses an ancestor will 'move' it's
properties to the ancestor, and the ancestor will only work with it's own
properties/handlers, and I'll avoid me.property and me.handler() calls when
i can do property and handler() calls. Otherwise I'll need all handlers in
a script with an ancestor to be duplicated in the script as a call of the
ancestor version of the handler, or to adopt a 'self' variable to use
instead of me when I NEED to always be talking about the script-itself's
instance.
Yeah, yeah, I noted myself that the toggle script which is going to be an
ancestor for a radio script AND ALTERNATIVELY a bizarre radio tree script
that a project requires isn't necessarily going to notice any difference in
performance between methods, but the question was 'which is faster' not
'will this specific example noticably run faster' or 'how would you do a
radio button?' (I've already got a toggle/radio button behavior that is all
in one, but it's old enough I figured I'd rewrite it as I'm adding this NEW
functionality in, and this new funcitonality requires the split to be
made.) I appreciate your attempts at offering other ways to deal with the
toggle/radio thing (we all can approach things from the wrong side
sometimes) but this time I think what I'm doing is the correct
approach. My main question, which I'm still letting settle a bit in my own
mind is: How do I write behaviors which can be used in the score OR used as
ancestors for other behaviors with the least amount of work and best use of
OOP methods? I think my answer is to move Props from the ancestor's GPDL
to the ancestor and be aware when me may not be me.
roymeo
[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!]
