strategies for mapping values and executing commands in RobotLegs

robotlegs_strategies.as

1. github.com/robotlegs/robotlegs-framework/blob/master/src/org/robotlegs/base/CommandMap.as:

// only one mapping possible

mapValues();
command = createCommand(mapping);
unmapValues();
command.execute();

2. github.com/joelhooks/signals-extensions-CommandSignal/blob/master/src/org/robotlegs/base/SignalCommandMap.as:

// multiple mappings possible

for each mapping
{
	mapValues();
	createCommand(mapping).execute();
	unmapValues();
}

2a. occurs to me that following the pattern in 1, 2 should be:

for each mapping
{
	mapValues();
	command = createCommand(mapping);
	unmapValues();
	command.execute();
}

3. I was originally thinking about the case where I maintain own list of mapped commands:

mapValues()
for each mapping
{
	createCommand(mapping).execute();
}
unmapValues();

4. but thinking about 2a this seems better:

commands = new Vector(commandCount, true);
mapValues();
for each mapping
{
	commands.push(createCommand(mapping));
}
unmapValues();
for each command
{
	command.execute();
}

It all rather depends whether you want the injection mappings to live for the life of the command.

If your command is a macro command then when you injector.instantiate(ChildCommand) you'll lose the ability to fulfil the injections in those child commands with the payload from this signal/event.

A powerful use case is where the payload passed to the original Command is itself a class for another command, or a reference used to then retrieve a class for a command - for example in a generic option processing Command where the specific option consequences are dynamic but you want to use the same command each time to process "A, B or C". Think of a multiple choice menu that is reused for various scenarios.

Do you have a concrete example of why it's wrong to execute before unmapping?

My perception that 1 is superior from 2 came from my understanding of Joel's tweet: "@alecmce command payloads are mapped and applied only in the scope of a single command instance to prevent bleeding the injections." (http://bit.ly/qJsXnU)

My confusion was with the implementation in SignalCommandMap.as, where elements are mapped before and unmapped after each command. I was trying to understand why that was, and understood that it was to prevent injections bleeding from command A to command B. I realize that I misunderstood What Joel was getting at; his solution allows macro commands but disallows injections from bleeding from command A to command B.

At first look it felt like he was doing much more work than is necessary, but I can see the point. Thank you for explaining!

Excellent. And - in addition, you've revealed that the current implementation of the event driven command map doesn't leave the mappings while the command is executed. I have a version that does, so I'm guessing that has been lost along the line and we don't have good tests for it. I'll add those!

Thanks - always worth asking the question because there are so many opportunities for assumptions... looks like we've found one here, even if it wasn't the droid you were looking for.