Kurt Griffin [EMAIL PROTECTED] on 2/24/01 7:43 PM wrote:
>
> Colin (Kettenacker, that is) has a similar approach to mine, so I'll toss in
> my 2 pence. It's an object, which is a different animal from a global. Think
> of an object as a behavior instance without a sprite. There are a few ways
> to store the object's memory address reference (one of which is in a global
> variable) which allows you to communicate with the object.
>
> Often, object-oriented programming involves a hierarchy of objects. What I
> think Colin is saying is that he has a manager object which is higher up in
> the hierarchy, and runs herd over the lower tier of sprite objects.
Bingo:)
> This
> essentially replaces the sendSprite and sendAllSprite calls - because the
> manager receives all messages that might be sent to sprites in another
> architecture, figures out which objects need to get a message, and passes
> the info along. I favor this architecture, because it helps you to adhere to
> a major oop tenant - encapsulation. For instance,
> sendAllSprites(#someMethod) broadcasts the message to any sprite with the
> "someMethod" handler to execute that method - often not a problem, but if
> there are some stray sprites around with behaviors attached that have that
> handler, you can get some confusing results. There are other advantages to
> oop, but encapsulation is a major one.
Exactly, polymorphism is another major one.
>
> If the manager object receives a method call that it will interpret and send
> to only the sprites that it manages, then things are better encapsulated.
> Behaviors are objects - if you take what you know about how behaviors store
> properties, you can abstract that knowledge just a bit, and you'll be
> thinking in terms of parent scripts as well as behaviors.
>
>> I'm not specifically saying that sprite(1) would set a property of
>> sprite(2), but that sprite(1) sending a sendallsprites would be received by
>> a number of sprites listening for the call that would do certain things
>> based on specific internal criteria. To me this is kind of the same way a
>> movie script would work, in that different sprites could do certain things
>> when getting a 'switchToThis" call. Based on intertal props within their PDL
>> list, they could then choose to do 'something' or ignore it all
>> together.....kind of like having an invisible global or sprite object
>> handler...
>>
>> I'm not saying I'm RIGHT - hell I could be entirely wrong and would love to
>> learn more -- but this is kind of the way I've been dealing with stuff..
>
> I wouldn't begin to suggest that you are wrong - using behaviors and movie
> scripts is a perfectly acceptable way to program. But if you can learn to
> use parent scripts to create objects that live only in RAM, then you might
> find other ways. I'm far from an oop purist, but over time, I've come to
> embrace objects as I've learned how to manipulate them. You certainly don't
> need oop - but you might come to like it.
And that is exactly the gist. One does not *have* to use parent scripts and
child objects to organize communications between sprites. Grimwerks method
is just as valid. I mean what is a child object -- nothing more then a
creature of RAM. What is a sprite script or behavior... same thing (once it
is instanced). Parent scripts and child objects are just another means of
getting the same job done. But one can come to appreciate the power of OOP
through child objects for several reasons some of which Kurt has mentioned
above. It is a large subject but Peter Smalls "Lingo Sorcery" goes a long
way to explaining the power of OOP in Director (in a very weird, sometimes
infuriating but thought provoking way).
>
> Apologies for butting in,
> Kurt
Butt in anytime you want Kurt, you probably explained the topic *way* more
clearly then I could have. I apologize to Grimwerks for not responding
sooner (I am buried in work currently and will be so for a while yet).
Thanks again to Kurt for fielding the question.
Hasta...
ck
[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!]
