Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

John Peacock wrote:
> Ken Williams wrote:
> 
>>I do still wonder about the need for this parameter.  The author  could
>>just as easily put the value in the options array, and probably  with
>>less typing.
> 
> 
> I also think this is needless frippery, but for the opposite reason.  How's this
> for an alternative definition:
> 
> The C<options> array is the list of displayed/prompted options to C<ask()> which
> a user can choose from; C<ask()> will not return until one of these values has
> been chosen.  The C<default> can either be one of the members of C<options> or
> some value to indicate that no answer could be obtained (such as would be the
> case if the Build.PL script had no controlling terminal).  As such, the union of
> the C<default> value with the C<options> array is the list of B<permissible>
> values, whereas the C<options> array is the list of values which satify an
> interactive C<ask()>.
> 
> This gets us both:
> 
> a) the total list of acceptable values, and
> b) a way to know for certain that the Build.PL script is running unmanned.

(b) is not possible. If the user presses <enter> or <ctrl-d> without 
typing anything, then the default will be used. So it's not an indicator 
of an unattended build.

> I don't see any reason to special case the $default <not-in> @options for a flag
> when we can infer it directly.

IIUC, Ken's original point was that the 'default' argument could be 
mistyped. Requiring the argument to 'default' to also appear in the 
'options' array is a safeguard and requires the author to verify or 
explicitly allow the differing value. I strongly agree with this; I like 
"safe" APIs.

The union of 'default' and 'options' does constitute the exclusive list 
of permissible values. It's just that 'default' must be explicitly 
declared to be different if it is not a member of 'options'.

Randy.