Just curious about the use of a map to pass parameters between a MessageSource and MessageListener.  (Both in BoyLib)

As an ancient programmer of imperative languages I tend to think of parameters being sent as lists.  I'm wondering what kind of situations would require a map from strings to strings.  Or to spin that another way, what possibilities a map from strings to strings might open up. 

I don't think any situations require the one representation or the other, as the two representations are easibly exchangeable (you can encode a parameter map as a list of alternating keys and values, or a parameter list as a values with indices as the corresponding keys).

I think it's largely a matter of preference which is used. Lists are probably somewhat more efficient to create and access, but maps are a bit more self-documenting (compare: some_func(2.67, 45) with some_func(velocity=2.67, angle=45))). Maps are probably prefered in loosely coupled systems where interfaces may involve in incompatible ways (it's no coincidence that query strings in HTTP requests typically use key/value pairs; i.e. maps, instead of argument lists).

Since the message source/listener protocol defines a loose coupling between senders and receivers of messages, the implementors apparently decided it was better to use a map, so a sender can be updated to include some extra parameters that most of the receivers do not actually use. This is possible with argument lists too, of course, but then you would have to add your new parameters at the end of the list, which could get messy after a while.

That makes sense, thanks.

I guess then this would be used somewhere outside of the core gameplay code then?  Something like a chat gadget that would almost literally be a sender to an unknown number of listener objects, which then transmit messages to whoever they're connected to?

Or maybe it *is* used to support core gameplay and I just need to try a different style of coding...  I guess when some event occurs, like in World of Goo when the player builds close enough to the pipe, a single message could be broadcast and the gooballs would receive it to change their state, the sound engine could receive it to turn on the vacuum sounds, the effects system could receive it and turn on the fog effect around the pipe etc.  That way you code the event once and can add and modify effects pretty painlessly.  The map from string to string would give you flexibility to pass whatever parameters you might need, at the cost of having to parse anything numeric when a MessageListener needs to receive a numeric parameter.  I guess that's small enough for game events (i.e. not per-frame events.)

Any opinions on that last paragraph?

Yes, the main benefit is that it allows for multiple listeners. In the game, there is a single Messenger instance (see BoyLib/Messenger.{h,cpp}) with which all interested components register; for example, if the user clicks the OK button in a dialog box, a message is broadcast through the messenger and the dialog box picks it up and closes itself in response.

In the game, the messenger is used to connect menu's and GUI components and such, but not in the implementation of the core gameplay, although I don't think there is a fundamental reason why it couldn't be used as you describe.

Yes, I continued to think about it after I posted and felt that the GUI would be the most obvious place to use the technique.  I'll start working on some menus and play around a bit with it.  Thanks again for your replies!