There are three possible "right thing"s: Kill the script midway through and restart (Scratch, Snap! default), drop the new message on the floor (Snap! "thread safe scripts"), and queue the new message. Jens points out that if your application is playing music, you want the new note to play right now, not at some semi-random later time. That's why we have thread safe scripts as an option rather than as the sole behavior. If you're trying to capture the user's keystrokes, that's the paradigmatic example in which you want the event queued.
And of course if you're doing some database operation, you don't want to leave the database in an inconsistent state.
This is about events in general, not specifically BROADCAST. Iirc we currently treat different events differently, which has the advantage that often we succeed in reading the user's mind and doing what they want without them having to think about these questions, but the disadvantage that if they do think about, they're likely to get confused.
But back to your example, it reminds me of how kids fill their Scratch projects with WAITs because they don't know how to use BROADCAST AND WAIT and they want two sprites to have a conversation. So they have to do a zillion timing runs, and then the project doesn't work right on their friend's computer that's faster or slower.
Yes, but I was thinking of the WAITs as some arbitrary computation that one doesn't know how long it will take (and perhaps is variable).
This thread is discussing two issues at once: (1) how multiple broadcasts work and (2) whether global variables are good enough to get around the lack of message parameters.
I feel most strongly that messages should have parameters.
Though regarding (1) I agree
Maybe what would help for (1) is a "Little Person" metaphor. Someone shouts a message and then everyone who is listening for that kind of messages does X. Do the listeners drop everything they were doing to react to the message or only those things they are still working on from the last time they heard that message?
As I understand things, because message is a global variable, Snap! cannot guarantee that the contents of message in the 1st if won't have changed when it processes the 2nd if (because another broadcast may have taken place.)
So, I think you have to go further than just making the message a list to minimise the wrong information being decoded and processed.
I've been thinking about this for a while, and I think I used the word "modularity" incorrectly in the original post.
Scratch's broadcasts have great modularity. If a project uses broadcasts, you can take a sprite from it and plop it into another project, and it can immediately start interacting with other sprites - all you need to do is send messages to and receive messages from it!
What they lack, however, is the flexibility to describe a variety of co-occuring interactions between individual sprites. For example, it's very difficult for multiple players and multiple enemies and collectibles to coordinate between each other.
My solution for Scratch specifically would be this: Give sprites ways to interact with the sender of a message. This means adding "sender" to sprite dropdowns, allowing sprites to detect if they've specifically touched the message's sender or to query values from it, and a block labelled something like "reply [message] to sender", allowing for two-way communication.
Edit: This would by no means solve all of the problems that broadcasts currently have, but it would go a long way towards making the broadcast mechanism easier to use, without cluttering the UI or potentially confusing kids with sprite references. Plus, I bet the Scratch Team would actually seriously consider it.
As for Snap!, it would probably be a good idea to add arguments to broadcasts. That way, you can send messages using actual sprite references, and it would be a "step up" from my suggestion for Scratch.
