Al Hospers (and others) wrote:
>OK,
>
<A bunch of different messages on this topic>
Sorry, I've been working on other stuff, and finally have a chance to
jump in here. A couple of things ...
I think the article that was originally cited here is very good.
However, it is slanted toward the Java programming point of view. I
don't know Java - I've never written a line of code in it, but I can
see from what the author is saying that apparently, Java has a very
different way of putting things on the screen than Lingo does. His
suggestion of passing a window thingy to an object and asking it to
draw it's information on the screen doesn't translate well into the
Director world. Here, we typically use behaviors for drawing, or set
the member of a sprite, or just stick some text into a field member.
But, overall, I like his idea of not using Getter methods. I don't
know how practical it is in real-world applications, but I think that
it is an _excellent_ design goal. I'll have to keep that in mind in
my programming. I have said in the past that if you find yourself
using too many Getter or Setter methods in an object, then you should
re-examine your object structure as you probably should have a
property defined in a different object (the one that calls the Getter
or Setter method(s) the most). I just took a quick look at my Getter
methods in my current project, and only a few of them really just
return a property variable. Typically, they do some operation on one
or more property variables before returning a value. So, I guess you
could call them service routines.
There are a lot of messages on this thread and I've just skimmed most
of them. I've been trying to understand where Al is going when he is
talking about a global QuickTIme object and a global Slider object.
Maybe I'm missing something, but wouldn't this make more sense as a
QuickTIme behavior and a Slider behavior. I guess I don't see the
need for a single global QuickTime object. Imagine if you had a
situation where you had two (or more) QuickTIme movies on the stage
at the same time. Rather than having special code to deal with the
two (or more) QuickTImes, just drag out a copy of your QuickTIme
behavior and drop it on each QuickTIme sprite. Same with the slider
sprite. Then, the question about communication comes down to
intersprite communication. Without getting into a big discussion
about how to get sprite numbers, an an example, you could just make
an assumption that the QUickTIme sprite assumes that the slider is in
spriteNum + 1, and the slider makes an assumption that the QuickTIme
is in spriteNum - 1, then they just use these spriteNumbers to
communicate. As the QuickTime plays, the QT behavior, in it's
exitframe handler, could do a "sendSprite" to the slider telling it
the percentage of completion. And, as the Slider is dragged by the
user, the slider behavior in its exitFrame handler, could do a
"sendSprite" to the QT behavior, telling it the percentage to go to.
Is this too simple? Am I missing something? While it may not be
"pure" OOP, I use global objects all the time, for things that are
not screen related (e.g., Sound Manager, Net Manager, Navigation,
etc.). Is there really a need for a global QT Manager here?
As for the original question of ancestor access, I rarely use
ancestors. I really dislike the fact that you are forced to use the
syntax of me.somePropertyName. It makes coding with ancestors seem
very wierd and unusually difficult. As long as I've been into OOP,
I've been looking for some editor/displayer which would show me a
full object's structure and properties. For example, if I create an
object from the A parent script, and it instantiates B as it's
ancestor, I would like to be able to see my A object in a way that
has all the methods from A and B grouped together, and all the
properties from A and B grouped together. That would make things
much clearer.
Irv
--
Lingo / Director / Shockwave development for all occasions.
(Home-made Lingo cooked up fresh every day just for you.)
[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!]
