Discussion: Add public function(s) `cmdinfo()`and/or `cmdspec()`

[tabulon]

Requesting feedback.

SYNOPSIS

Add public function(s) cmdinfo()and/or cmdspec()

The WHY

As a means to enable some more stuff, including but not limited to #17 (usage_desc and program_name()), and even more down the road.

The WHAT

Introduce a new public function, that employs a trick similiar to GLM's optspec(), but this one would be scoped around the entire 'command/program' rather than just one option, resulting in something along the lines of:

IDEA 1

use Getopt::Long::More;

GetOptions(
  cmdinfo ( usage_desc => '%c %o <some-arg>',
            summary => 'Awesome garbage grinder',
          ),
  'foo=s',
  'bar=s', optspec( required => 1, )
)

The cmdinfo function should also allow for a shorthand signature such that, the following is acceptable:

GetOptions(
  cmdinfo ( '%c %o <some-arg>', summary => 'Awesome garbage grinder', ),
  'foo=s',
   ...
)

that will become, in the degenerate case:

GetOptions(
  cmdinfo ( '%c %o <some-arg>' ),
  'foo=s',
   ...
)

which makes things quite similar to the GLD way; resulting, hopefully, in the least amount of surprise for that API school.

IDEA 2

Similar to the cmdinfo() function (that is scoped ONLY around things related to the 'command/program' as a whole), GLM could provide a cmdspec() function.

The cmdspec() function would accept, in addition to stuff digestable by cmdinfo(), also stuff related to its options.

This could enable supporting even "more stuff" down the route, such as eventually being able to devour the semantic equivalent of something like a Rinci $SPEC{}, or similar.

From the outside, cmdspec() would like something along the lines of:

GetOptions(
  cmdspec ( usage_desc => '%c %o <some-arg>',
            summary => 'Awesome garbage grinder',

            options =>  [ 'foo=s',
                          'bar=s', optspec( required => 1, )
                        ],
          ),
)

Note the current Getopt:: focus in the above, which is the priotity here. But nothing should forbid us from introducing, later on, other goodies (such as the Rinci args) that are mappable to Getopt-ish concepts.

Meanwhile, it should always possible for some other function, that we may not even be aware of, to do that kind of experimental mappings before feeding cmdspec() with its initially limited diet.

DISCUSSION

Idea 2 (i.e. cmdspec() ) appears to be quite promising going forward, but it needs more careful reflection/consideration before appearing in the public API.

Idea 1 (i.e. cmdinfo() ) appears to be more easily and readily achievable in the short run, which should quickly enable things like usage_desc, that are required for GLD feature parity.

Of course, one possible way of dealing with the dilemna would be start out with a function named cmdspec() from the outset which would initially support only what cmdinfo() would have supported, but even that would require more initial reflexion because of future considerations.

So, it migh be best to start out with a function whose scope is the 'command/program' ONLY AS A WHOLE, as in the case of cmdinfo() above.

Keeping in mind that this cmdinfo() might later end up becoming:

a) just a mere alias to cmdspec() b) A lower level thingy, useful even in the presence of a cmdspec(), with its employment shifted towards more internal usage. c) deprecated (probably forever, as how things usually go, ....)

---

Something tells me that (b) is what will probably happen; as I can see an indpendant use for this cmdinfo() thingy.

---