REQUEST: Do not require a "handler" to be passed to optSpec()

[tabulon]

Hi Perlancar,

I am creating this issue is to track a possible discussion about the "design divergence" (between GoL and GLM) concerning the treatment of missing handlers/linkages), as mentioned by the pull-4 that I have just submitted. The relevant section of the text is recopied down at the bottom for easy reference.

If that PR is merged, than it becomes very simple (only a few lines to change/delete) to align with the GoL approach, and let it do its DWIM in the case of missing a (handler => ) argument to OptSpec -- provided that, you agree, of course.

One possible objection could be the extra anti-fat-finger guard that is presumably obtained by the current behaviour (of forbidding a missing handler); since <Getopt::Long> would then try to put option values in global variables... which may or may not trigger an error message, depending on "strict" and "warning" settings., ...

However, the gained DRY goodness easily outweighs that concern, imho; especially considering that most migrations nowadays would probably involve -the already DRYer- hash-storage mode of Getopts::Long.

In fact, on the countrary, I suspect that most existing GLM users would want to go ahead and clean up unnecessary "handler => " lines in their code whenever they get a chance... And, if they don't, their existing code will go on working, without anything breaking.

Anyhow, if really needed, I guess the behaviour could made to depend on a configuration option, which would require to decide on "with what default"?

All in all, introducing a config option is probably overkill in this situation, imho. And if we do, I woud vouch for the new proposed behavior to be the default. After all, it would be perfectly backward compatible with existing functioning code... and the least surprising behaviour for new adopters.

My 2 cents.

Cheers,

---

BACKGROUND

shortened and copied over from pull request 4

...

There are two scenarios where behaviour in this matter (i.e. what is acceptable as a valid "linkage"/"handler") diverge significantly between GoL and GLM :

• 1) Slight divergence in design (Under discussion here)

  **GoL** happily accepts the situation where the "linkage" is not
  provided for a given "spec" (and takes it as an opportunity)
  to offer more **DRY & DWIM**);
  
  Whereas GLM goes ahead and forbids this case by refusing to
  create an OptSpec object without a defined "handler"; thereby
  preventing any such DRY & DWIM that could have been natively
  provided even by GoL itself.

• 2) GLM bug #3, hopefully fixed by pull-request-4, once merged.

...

Point (1) is clearly a design choice that would need further discussion before any action, and that's what this issue is for.

[perlancar]

I agree wholeheartedly. If GL does not require explicit "linkage", GLM should also not require explicit linkage. I will go ahead and code this.

[perlancar]

Implemented in 147a1f4.