orxCommand API improvement suggestions

[enobayram]

I would like to make two suggestions to improve the orxCommand API:

1) Expose orxCommand_Process, i.e. allow user code to bind an orxOBJECT to a command evaluation. orxCommand_Process is currently defined as a static function.

2) Provide a way to programmatically push values onto the command stack. And later when we have named variables in command blocks, provide a way to programmatically bind values to named variables.

[iarwain]

1) It feels to me you'd rather have an extra parameter to the already existing orxCommand_Evaluate(). That parameter was willingly hidden at first though. Can you give me a case scenario where it'd make more sense to have this rather than using a timeline or sending an event?

2) I'm not sure I see the use case for this one either. If you are the one emitting the commands programmatically, why not calling orxCommand_Execute() with the correct parameters instead of pushing them onto the stack?

[Enis BAYRAMOĞLU]

Sorry, I should've indicated my motivation. Think of these two points when you're evaluating this suggestion:

a) These two methods are not meant to be used by the end-user. They're more meant to be used for extension libraries on Orx.

b) They intend to expose functionality that's already in Orx in order not to repeat code.

Reply to your questions:

1) It feels to me you'd rather have an extra parameter to the already existing orxCommand_Evaluate(). That parameter was willingly hidden at first though. Can you give me a case scenario where it'd make more sense to have this rather than using a timeline or sending an event?

Think of my generalized orxFX suggestion. In order to implement that, you need to duplicate the orxCommand functionality that parses '^', but the functionality is already there buried in the orxCommand module.

 

2) I'm not sure I see the use case for this one either. If you are the one emitting the commands programmatically, why not calling orxCommand_Execute() with the correct parameters instead of pushing them onto the stack?

Again, referring to the generalized orxFX suggestion, you, as the Orx extension library author, are not writing the command, you're providing a context for the command to be run.

 

The generalized orxFX suggestion is the second time I need these two functions BTW; the first time I needed them was in my behavior tree code.