perlancar / perl-Getopt-Long-More

1 stars 1 forks source link

Request : Relax checks for `optSpec` hash keys #2

Closed tabulon closed 5 years ago

tabulon commented 5 years ago

Hello Perlancar,

While I was at it, I thought I woud also add in a very small change resuest concerning the 'optSpec' object.

Often times I feel the need to store some additional information along with the option definition; either for automation or further documentation purposes, quite similar to the underlying motivations for using the Getopt::Long::More module.

The best place to put those would be the optSpec objects that I can store somewhere before passing them to GetOptions, but currently that's not possible because optspec() won't allow it 👎

Inspecting the code reveals that optSpec->new() refuses to ingest anything other than the attribute keys known to itself, similar to those un forgiving Moosy thingies...

While that kind of extreme strictness may be preferable under some circumstances, I am not sure what it serves here.

Since this is really a small "utility" object, it would probably not hurt to allow carrying some additional information passed in by its users...


Here are two possible alternatives for this:

a) Behave like a spongy object, without any unnecessary restrictions. b) Allow some additional patterns for the keys that would be reserved for the user, such as: 'x', 'X', or any key that starts with a dash (-) or an underscore(_).

Below are suggested patches for the above alternatives. Any other solution that allows storing at least one piece of information in there is also welcome.

PROSPOSED PATCHES (2 possibilities)

The following snippets all refer to the new() constructor of the OptSpec object.

CURRENT CODE

   ...
    for (keys %$obj) {
        unless (/\A(handler|required|default|summary|description|completion)\z/) {
            die "Unknown optspec property '$_'";
        }
    }
   ...

PATCH alternative (a)

    #  just do away with gatekeeping by deleting the above snippet

PATCH alternative (b)

    for (keys %$obj) {
       # allow some additional patterns for the keys that would be reserved for the user.
        next  if  /^[-_]/  || /^x$/i;     # The keys 'x', 'X', or any key that starts with a dash or an underscore
        unless (  /\A(handler|required|default|summary|description|completion)\z/ ) {
            die "Unknown optspec property '$_'";
        }
    }
perlancar commented 5 years ago

I agree with allowing extra properties. The way I do this in DefHash is similar to what you suggested: allow (ignore) any property that starts with "x." (note the extra dot) or "_". I'm going to just go ahead and code this in f5ec9bd. Thanks.