On Fri, Jun 23, 2006 at 06:55:28PM +0300, Markus Laire wrote:
> On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> >An alternate interpretation would be that the last one is actually a 
> >compile-
> >time error because none of the sigs match (Int,Int) and for a call to
> >work with 2 Int parameters, you'd need to be explicit:
> >
> >talk(~123,3);
> >
> >But I'm not sure which way perl6 actually leans.
> >
> >Though it seems to me that automatic type conversion by the compiler is
> >a way to get yourself in trouble.  Not that perl shouldn't let the
> >programmer get himself in trouble, but this seems like one of those
> >things that should require asking to turn on rather than asking to
> >turn off.
> 
> Synopsis 12 at
> http://dev.perl.org/perl6/doc/design/syn/S12.html
> says
> <quote>
> When you call a subroutine with a particular short name, if there are
> multiple visible long names, they are all considered candidates. They
> are sorted into an order according to how close the actual types of
> the arguments match up with the declared types of the parameters of
> each candidate. The best candidate is called, unless there's a tie, in
> which case the tied candidates are redispatched using any additional
> tiebreaker long names (see below).
> </quote>
> 
> IMHO that seems to mean that in my example the (String, Int) version
> would be called because it's "the best candidate". And that would also
> mean that first Int is automatically converted to String.

I don't think so. I think the "best candidate" prose is about
choosing from types that have been specified, not autoconverting
between types such that one of them will match the long name. In
other words, when you have

    multi sub foo (Num) { ... }
    multi sub foo (Int) { ... }

    foo(1);
    foo("123");
    foo("bar");

foo(Int) is the best candidate for the first one because 1 is an Int.
But in the second and third calls, there is no "best candidate"
because strings were passed.  Would you expect the third call to
succeed because "bar" can be converted into the number 0?

The programmer put type information in the sig for a reason. I think
that reason is that they wanted to be careful about what was allowed
to be passed to the subroutine.  Autoconversion seems to defeat that.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Reply via email to