tag:robotlegs.tenderapp.com,2009-10-18:/discussions/suggestions/45-returning-command-instance-from-icommandmapexecuteRobotlegs: Discussion 2018-10-18T16:35:23Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/53064862011-02-12T21:44:41Z2011-02-12T21:44:41ZReturning command instance from ICommandMap.execute()<div><p>Hey folks,</p>
<p>I've been doing a bit of work on the Macrobot extension
(<a href="https://github.com/Aaronius/robotlegs-utilities-Macrobot">https://github.com/Aaronius/robotlegs-utilities-Macrobot</a>)
and came across a need for ICommandMap to return the executed
command instance from its execute() function. This arises out of
the need for a macro command to track asynchronous subcommand
completion. The method employed within Macrobot is that an
asynchronous command has a dispatchComplete() method which not only
releases the command from memory but marks itself complete and
calls any registered listeners. The sequence command can register
to be notified when the subcommand completes. When the subcommand
notifies the sequence command that it has completed execution, the
sequence command can execute the next subcommand in the
sequence.</p>
<p>Previously, the macro commands were completely in charge of
fulfilling injections into subcommands as well as execution. This
worked fine but you lose the benefits of having a single point of
command execution through a context's command map. In one case, I
wanted to add logging capabilities to my context's command map to
record when any command was executed. However, since macro commands
directly handled the execution of subcommands, the command map
would not know about it and therefore the subcommand's execution
would never be logged.</p>
<p>So, for Macrobot I created an optional IMacroCommandMap
interface and concrete implementation that allows macro commands to
use the IMacroCommandMap to execute any subcommands. This allows
for a single point of command execution as I described previously.
If ICommandMap returned the command on execute, the macro command
could first check to see if the subcommand is already complete
(which could happen if an AsyncCommand immediately dispatches
completion, that is, it's not really asynchronous) and, if it's not
already complete, add a completion listener to the instance.</p>
<p>You may feel a bit queezy making this modification as returning
the command instance could introduce some coupling issues if
developers chose to mis-use it (maybe I'm one of those). If that's
the case, no problem. I just thought I'd throw it out there in case
it could be useful for other extensions as well. At least for
Macrobot, it would do away with the need for implementing a custom
command map.</p>
<p>In addition, if I'm on the wrong track and you see a better way
to handle the macro command scenario, please, let me know.
Thanks!</p></div>Aaron Hardytag:robotlegs.tenderapp.com,2009-10-18:Comment/53064862011-02-13T16:45:59Z2011-02-13T16:45:59ZReturning command instance from ICommandMap.execute()<div><p>Hi Aaron, unfortunately changing the return type of a function
is a breaking change - so we can't do it in RL 1.x because of
semantic versioning.</p>
<p>Any utility / code that implements ICommandMap or extends
CommandMap would have to be altered to match the new return type,
so it's no dice for now.</p>
<p>I'll put it on the 2.0 list for consideration though,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/53064862011-02-13T17:10:02Z2011-02-13T17:10:02ZReturning command instance from ICommandMap.execute()<div><p>Understood. Thanks.</p></div>Aaron Hardy