"Aldo Calpini" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
> >
> > After the New And Improved logError() routine is rolled out, it seems to
me
> > that this log statement should generate a compile-time error, since the
> > named Int parameter "prio" is given a non-integer argument "HIGH". At
best,
> > this should be a run-time error. Either way, this confusion undermines a
key
> > Perl strength: ability of the user to upgrade code (without breaking
it).
>
> I strongly disagree. this fact has nothing to do with Perl itself, but
> with how you decide to use it. you said "Int +$prio" because you
> *wanted* code to break when "prio" is not an integer.
I think my statement above was confusing. The "should" in "this log
statement should generate a compile-time error" meant "if my understanding
of the Apocalypses is correct, this is how Perl 6 *will* behave". The
example was intended to illustrate a case where the method designer never
expected users to invoke the method with a Pair whose key is the string
"prio". As far as the designer is concerned, he added a new optional
parameter to the API (namely "Int +$prio = 4") that should not and could
not break any existing calls.
Specifying the parameter as type Int (as opposed to being typeless) was not
intended to break any existing code, since no existing code could possibly
be specifying the brand-new parameter named "prio". Rather, it is a
reasonable way for the designer to ensure that all newly written calls
explicitly supplying the prio parameter give it an expected Int-typed value.
"Aldo Calpini" <[EMAIL PROTECTED]> further wrote:
> we have to cope with new (and greater) strengths in Perl6, and one of
> these is: "it's fine for Perl to have a type system as long as it's
> optional" (cit. A6).
>
> if you upgrade your code to do type-checking, it obviously fails when
> type constraints are violated. But you don't have to. You could have
> said:
>
> sub logError($msg, +$prio = 4, *%errorInfo) {
> # ...
> my Str $prio_desc = getPrioDescription($prio) // $prio;
> print "$prio_desc: $s.\n";
> }
I agree: optional type-checking is a great strength of Perl 6. However, I
don't want to overly complicate my problematic example; type-checking is not
the real problem, it's semantic consistency. I just used types to illustrate
the most dramatic unintended change possible: previously correct code that
will no longer even compile after the additional of a new optional parameter
to a subroutine.
The method designer could indeed add defaulting logic like " // $prio" as
you indicate above. However, this is only possible if he anticipates that
callers might try to pass non-integer prio values to the method. Since the
parameter is intended to accept an Int, I don't think a method writer should
admit other values. In this admittedly contrived example it might be
possible, but in general when you want an Int (say to internally look up an
element by index), you cannot accept an alterative.
Other legitimate objections to the example notwithstanding, the main point
is this: there should be a very clear language-enforced distinction between:
(A) a method invocation passing a parameter by name
(B) a method invocation passing a Pair object to a positional Pair
parameter
(C) a method invocation passing a Pair object to the slurpy hash
Since my understanding of the need for and use of the slurpy hash is still
limited, I just contrasted case (A) to case (C), but IMHO the concept
applies accross all the categories.
Just my 2¢ (or to be Perl 6 syntax-correct, my ¥2 ;-).
-Dov
