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();
}

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.