More Stuff: Add support for Subcommands, similar to <GL::Subcommand>

[tabulon]

SYNOPSIS

Add support for subcommands.

Here's a conventional description of subcommands taken from the CLI11 project:

Subcommands are keyword that invoke a new set of options and features. For example, the git command has a long series of subcommands, like add and commit. Each can have its own options and implementations.

The WHY

Subcommands (sometimes simply called 'commands') have been quite popular for some time now.

While certain aspects of subcommands (such as the actual dispatch) would arguably be best treated by a CLI framework, certain other aspects (such as the need to specify and parse command line options) clearly have an interplay with 'GetOpt' functionality.

If the options parser (GLM, in this case) does not provide simple mechanisms for supporting this sort of thing, then many wheels need to be re-invented by CLI frameworks, or worse, command scripts themselves.

The WHAT

GLM itself should not be providing a full-fledged dispatch mechanism, which is probably the job of a higher level CLI framework.

Instead, GLM should simply lay out the groundwork for easily building such a mecanism.

The API MECHANISM

CONSIDER: Adopting a subcommand API that is conceptually quite similar to that of (Getopt::Long::Subcommand),.

Meanwhile, GLM's GetOptions() needs to remain compatible with GOL, which provides additional incentive to investigate an approach à la cmdpec() as mentioned in #18.

---

[perlancar]

I agree that cmdspec() (#18) is the mechanism to introduce this feature into GLM in a GoL-compatible way.

[tabulon]

Which one of the below interfaces do you like better?

a)

GetOptions( cmdspec(
   ...
   subcommands => { ... },   # or simply, "commands"
   ...
));

b)

GetOptions( cmdspec(
  ...
  options  => [
    'foo' => optspec (...),
    '&list'  => cmdspec (    # not sure about the &
        ...
     ),
  ],
  ...
));

I see merits for both, but (a) is probably the way to go. It's just simpler.

[perlancar]

I prefer a) and "subcommands". Command, IMO, should refer to the program/script, to avoid confusion.

[tabulon]

Agreed.