Composite vs Full Commands

[Castleberg]

I have to assume this has been asked...but for the life of me I can't find the thread...

I have several scenarios where composite commands would be logical, however, I currently have full commands that are just set to execute another command...

i.e...

do this, and this..

((Execute  this command))

My question is...is there some advantage to doing this with composite commands instead? It seems there are drawbacks (they can only be run in pairs... But I don't see any advantage.

Is it faster? What am I missing...

[Pfeil]

"Composite" (prefix/suffix) commands are a feature that predate, and have largely been superseded by, dynamic command sections.
As such, they are mainly used for backward-compatibility, and perhaps niche purposes where dynamically combining two halves of a command is called for, without needing to use conditions for each possible variation.

[SemlerPDX]

...
My question is...is there some advantage to doing this with composite commands instead? It seems there are drawbacks (they can only be run in pairs... But I don't see any advantage.

Is it faster? What am I missing...

Pfeil explained it perfectly.  As a real world example, I found it necessary to use composite commands for a public profile for reasons including reduced total number of commands and/or reduced redundant repeated code/command actions, as well as simplicity and organizational purposes for future editing in addition to improved readability by the end user(s).

In my AVCS4 Falcon BMS Radio Menus profile, pilots speak who they are talking to followed by what they need to do, such as, "Wingman Say Fuel", or, "Flight Fence In", or, "Wingman Fence In".

I set all the 'prefix' words to their own prefix command(s), since the 'suffix' words could be attached to any of the prefix command options (as shown above).  The suffix commands themselves contain the meat and potatoes of command actions, where the prefix used simply sets a text variable to 'WINGMAN', 'ELEMENT', or 'FLIGHT' which can be checked inside the suffix command(s) if needed.

Imagine you had many commands that "Turn ON" or "Turn OFF", followed by the thing they are turning on or off, maybe 'Lights' or 'Engines' ... the 'Turn' command(s) could be a prefix or pair of prefixes, and the things to turn could be suffixes.  This is not needed, but is one way you can attach many command actions to common prefix words, where those command actions could vary wildly from each other, yet the common prefix is always a matter of "ON" or "OFF".

Sometimes, even though we could combine all of this into one single command, it can be helpful for editing or end users to have a more organized flow and intuitive layout of commands, and (IMHO, when appropriate) the composite commands fill this niche perfectly.

Here's an example of how my AVCS4 BMS Radios profile uses composite commands for organization/readability:


*(also shown, use of variable command phrases on text variables using {TOKENS}, so I can edit what is recognized as a command through a config file change, loaded during profile initialization)


*(click to enlarge - simplified example from old version, showing use of preset variables through {TOKENS} to retrieve keys to push or number of times to push a key)