<snip>

1) have the object publish the data publicly to a global variable?

this will work fine, tho I just try to keep globals down.
<snip>

This one works just fine if speed is the issue here. Kerry had mentioned a
project he tackled a while back which illustrates this point very nicely.
He had a sprite bouncing around on stage amongst other sprites and he
simply used a global to remember the position of the main sprite. A pure
OOP method meant using a sendAllSprites (there were 40 sprites if I
remember correctly) or a call on the list of sprite behaviors. Globals made
things easier for code management and also took fewer processor cycles. I
think I still have that thread saved on my machine at home.


<snip>
2) have an accessor method in the object so the slider can get the
data as needed?

this one goes against all the OOP principles that are expoused by the
big guys/gals, but it works well.
<snip>

I use this method when writing generic behavior libraries. In fact, even if
the method simply returns a single property without performing any other
steps on it, I prefer this method. The reason being this:
When I write the script, I may want it to perform only one activity -
return a particular property as is. But later if I need to do some
pre-processing on the property before returning it, its more difficult to
go and change the accessing syntax in the rest of my scripts. For example:

foo = gObject.someProperty
This will return only the property as is.

foo = gObject.SomeHandler()

----- In foo ----
on SomeHandler()
     -- Process property
     -- Return new value instead of original property
end SomeHandler()

This one saves me a few steps that I might have to put in my other scripts
that use the data returned by the foo object. Execution speed does suffer,
though. Small price to pay for reusability.

<snip>
3) duplicate the movie location monitoring functionality in the slider
behavior?

this is OK but I hate duplication, and keeping this functionality in
the main object means that I only have to update it in one place.

4) include the slider functionality in the object?

IMHO this makes the object way too big & unwieldy.
<snip>


I agree with Al on these two counts


My general opinion is that globals are good when speed is of importance.
However, too many globals are a strict no-no. How much is too much? That
depends on the size of the project and the comfort of the programmers.
Objects are good while building reusable code libraries.



[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!]

Reply via email to