FAQ
I'm sending this also to perl6-language, in case someone there knows
an answer to this.
On 6/23/06, Jonathan Scott Duff wrote:
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?
I think you are right, but I don't see that mentioned anywhere in Synopses.

S12 clearly says that for a particular short name ("foo" here) *all*
visible long names ("foo(Num)" and "foo(Int)" here) are candidates and
best candidate *is* called (no matter how bad it is) -- unless there's
a tie.

So that would seem to say that for foo("123") above foo(Int) would be
called because it's the best candidate.

Which one is "better" for foo("bar")? foo(Int) or foo(Num)? Or is that a tie?

And what about other types?
e.g. if String can't ever be "best candidate" for Int, then does that
mean that neither can Int ever be "best candidate" for Num, because
they are different types?
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
duff@pobox.com
--
Markus Laire

Search Discussions

  • Jonathan Scott Duff at Jun 23, 2006 at 6:53 pm

    On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
    And what about other types?
    e.g. if String can't ever be "best candidate" for Int, then does that
    mean that neither can Int ever be "best candidate" for Num, because
    they are different types?
    Well, I think Num and Int *aren't* different types because as far as
    duck typing goes, Num does Int. I wouldn't expect that String does
    Int though (at least not without some help :).

    The way I see it, the types specified in the signature are like
    constraints. When you say

    sub foo (Num) { ... }

    the signature says that "only an item that can perform the Num role may
    fit in this slot". When perl tries to match Capture to Signature,
    it checks the type of each argument in the Capture against the
    "does list" for each parameter in the Signature. If the argument type
    appears in the "does list" of the Signature, then it's a match and all
    is well. Otherwise it's an error. Since "Num does Int", a call such
    as C<foo(10);> succeeds.

    At least that's my vague interpretation of this aspect of perl6 at
    this moment. :-)

    -Scott
    --
    Jonathan Scott Duff
    duff@pobox.com
  • Paul Hodges at Jun 24, 2006 at 2:48 pm
    so back to foo("bar"). What's the default behavior? String doesn't Num,
    does it? though is does convert if the value is good....

    Does that mean foo("123") should or should not dispatch to foo(Int)?
    Or even foo(Num), for that matter.... Oy, I could see some headaches
    around setting these rules in mind, lol.... What's the DWIMmiest
    behavior hear?

    I assume foo(1) would dispatch to foo(Int) rather than foo(Num), as the
    most restrictive fit, and I could see how that could blow up in my
    face. Is there some basic compile time warning (and a way to tell it
    "shut up, I know what I'm doing") that says "hey, these are
    suspiciously close signatures, are you sure this is what you wanted?"

    Is the difference that foo("123") can be easily converted to foo(123)
    without data loss, whereas foo("bar") to foo(0) cannot?

    --- Jonathan Scott Duff wrote:
    On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
    And what about other types?
    e.g. if String can't ever be "best candidate" for Int,
    then does that mean that neither can Int ever be "best candidate"
    for Num, because they are different types?
    Well, I think Num and Int *aren't* different types because as far as
    duck typing goes, Num does Int. I wouldn't expect that String does
    Int though (at least not without some help :).

    The way I see it, the types specified in the signature are like
    constraints. When you say

    sub foo (Num) { ... }

    the signature says that "only an item that can perform the Num role
    may fit in this slot". When perl tries to match Capture to Signature,
    it checks the type of each argument in the Capture against the
    "does list" for each parameter in the Signature. If the argument
    type appears in the "does list" of the Signature, then it's a match
    and all is well. Otherwise it's an error. Since "Num does Int",
    a call such as C<foo(10);> succeeds.

    At least that's my vague interpretation of this aspect of perl6 at
    this moment. :-)

    __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-users @
categoriesperl
postedJun 23, '06 at 6:11p
activeJun 24, '06 at 2:48p
posts3
users3
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase