Re: possible ":method" bug/misfeature

[Tom Christiansen <tchrist@chthon.perl.com>]

>tc> Here's the issue: I fail to see *why* it suppresses that
>tc> warning, as it still applies.

>No, it doesn't.  You said, "I'm only planning to use this as a
>method.  I know it's not necessarily available as a first-class
>sub name.  Shut up about that."  You got what you asked for.

>This warning suppression per-subroutine is specifically so that
>modules can have methods named after builtins, and yet still
>invoke the builtins internally without having to replace all
>instances of (e.g.) send() with CORE::send(), which looks ugly,
>just to shut up that warning for known subroutines which we never
>intended to have supplant the builtin.  The warning and the
>renaming are a real pain in the ass, and an affront to module
>writers who never considered the usage just described to be
>ambiguous (since it never was).

There's something very strange here, then.  I believe that the
warning in question *never* triggers on method calls that conflict
with built-ins, irrespective of a ":method" attribute.  Witness:

    sub oct { 042 }
    $n = main::->oct(9999);
    print "n is $n\n";

    % perl -w /tmp/testmeth
    n is 34

One or both of us seem to be missing something here.

--tom

---

Follow-Ups from:

Ronald J Kimball <rjk@linguist.dartmouth.edu>
Spider Boardman <spider-perl@Orb.Nashua.NH.US>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---