OOPS! You've just opened up a whole can of worms on proper OOP protocol
> I'm really just curious here; I've been doing a lot of projects utilizing
> sendsprite and sendallsprites -- between the two of those, which
> is better?
> Obviously knowing the specific sprite is 'better/faster', but if
> you didn't
> and didn't need to target a specific sprite, but more targetting a sprite
> with a specific behavior, does sendsprite work faster than sendallsprites?
> Don't know why, but I'd imagine it would...
Well if you are targeting a specific sprite then sendsprite is certainly
faster then sendallsprites. However if you are targeting a specific
method/handler of a sprite script then I believe the call command is even
faster yet.
>
> Now, with this all in mind is it better to have a moviescript change a
> global that all the sprites are paying attention to or is just as 'ok' to
> have sprites change properties based on their conversations to each other?
> Obviously the one makes debugging easier, but with
> (sprite(17).pMyInfo) you
> could debug that way as well...
I'm not 100% clear on what your asking here, but I'll take a stab. I think
it gets down to a matter of scope. Generally speaking I tend not to use
sendsprite or sendallsprite but rather use child objects. If my sprites need
to communicate with each other usually I will have a sprite manager object
of some sort that each sprite will report to in the beginsprite handler.
Then each sprite (or group of sprites as the case may be) will have it's own
object defining it's characteristics and functions. If one sprite object (or
group of sprite objects) needs to communicate with another sprite object (or
group of sprite objects), I route the call through the sprite manager object
as it will be aware of exactly which sprites belong to which object. It is
probably not as fast as making a direct call to a sprite' script using the
call or sendsprite command, but it is certainly easier to manage when facing
complex groups of objects.
If the scope is small (i.e. you have only a few sprites that need to
communicate between each other) then sendsprites or even sendallsprites can
be adequate (though I still tend to avoid them and use child object instead,
as I am never surprised anymore when the client wants the scope of a project
to be expanded).
As to sprites changing the contents of their properties (based on the
interaction between each other), I think this can is a common occurrence in
programming (I know that I do it often). You may want to obey the rules of
OOP and not allow direct access from ones sprites/objects properties to
another sprites/objects properties as this can be risky. Especially if you
work with other programmers on the same project. As for debugging, a well
written network of objects can be extremely easy to debug when things aren't
working as you planned. It can really make your life a whole lot easier.
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!]
