send_vs_call

send vs call Big concepts: -- In D4+ and with regular parent/child you can always use direct messaging, such as "SomeFunction(someObject)". In later versions this can work with sprite and scriptmember objects too. If the message cannot be handled there will an error. -- The three new broadcasting methods in D6 (sendAllSprites, sendSprite, and call) have two advantages: they can send messages to multiple objects, and if the message cannot be handled there won't be any error. -- The more objects you're passing messages to, the more microcycles. Other things being equal, don't sendAllSprites if you can sendSprite, and don't sendSprite if you can call to a partner behavior. (These calculations pale beside media-loading and display calculations, though.) -- The big danger with broadcast messages is namespace collisions. If you're broadcasting a message, please make sure you're using a unique name... "sendAllSprites(#init)" could have unintended consequences! ==================== btw, one trick you can use for protecting a behavior from inadvertent broadcast messages is to include a self-reference argument: on PrivateMethod me, caller if caller <> me then exit -- do private things This requires the extra line in each protected handler, as shown above, and also requires a slightly different calling syntax from inside the behavior: on beginSprite me PrivateMethod me, me end Because a broadcast message won't know the specific identity of objects it's talking to, it won't be able to include that self-reference argument. ==================== jd