| Subject: | Parameter Checks In Case of Allowed UNDEF Type |
For type validation it is possible to combine several allowed types:
validate( @_, { foo => { type => GLOB | GLOBREF } );
It is also allowed to use a combination like:
validate( @_, { foo => { type => SCALAR | UNDEF } );
An additional regexp check would be implemented e.g. like this:
validate( @_, { foo => { type => SCALAR | UNDEF, regex => qr/\d+$/ } );
If the value of foo is undefined in the last example, the regex is explicitly checked against
the empty string ('') instead (according to the manual). However, since an undefined type is
_explicitly_ allowed by the type check constraint it does not really make sense to apply an
additional regex check (or other checks) in this case. With the current implementation I have
to specify a regex that tries to match a defined scalar value and that always matches an
empty string (in case of an undefined parameter). For the example above his would probably
look like this (I want to check for positive integers):
validate( @_, { foo => { type => SCALAR | UNDEF, regex => qr/\d*$/ } );
As a consequence it is not possible to distinguish undefined values (which are acceptable)
from empty strings (which are not acceptable by the app) because the regexp will match in
both cases. In my opinion the proper behavior would be that no further checks are being
applied to a parameter in case it is undefined and an undefined value is explicitly being
accepted by the type check. In this case only a default value should be assigned (if present).
Does this make sense or do I just miss the right way of applying the validation rules?