Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

•Re^4: goto superclass method

by merlyn (Sage)
on Dec 22, 2004 at 23:19 UTC ( #416947=note: print w/replies, xml ) Need Help??


in reply to Re^3: goto superclass method
in thread goto superclass method

Huh? Your example shows that both UNIVERSAL::can and SUPER::can on asking how a "Baz" can "bar" return the same code (which is Baz::bar), and that SUPER::bar for Baz is in fact the one in Foo::bar.

That's exactly what I said. You didn't show "wrong" on anything. Did you mean something else?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^5: goto superclass method
by Aristotle (Chancellor) on Dec 22, 2004 at 23:48 UTC

    You claimed the current __PACKAGE__ affects the result of Foo->SUPER::can( 'bar' ):

    when you start saying sub Foo::bar, the __PACKAGE__ doesn't change to Foo, so you have a problem with SUPER.

    I posted code where changing packages, and thus __PACKAGE__, is inconsequential, contrary to your claim.

    So the reasoning in my initial post about why the goto there is an infinite loop is correct.

    Makeshifts last the longest.

      You claimed the current __PACKAGE__ affects the result of Foo->SUPER::can( 'bar' )
      Nothing of the kind. Why do you keep saying SUPER::can? That's really weird. That's "the can method that isn't in the current class". Unless you've implemented a local "can" method, that's gonna be UNIVERSAL::can.

      Please go back and reread what I wrote. It's still true, and your example doesn't show anything to the contrary. I said that SUPER:: is affected by __PACKAGE__, and __PACKAGE__ is not affected by the package name of the subroutine, but only by package directives. Your "infinite" loop is for reasons other than what you state, because your hypothesis is incorrect.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        That's really weird. That's "the can method that isn't in the current class". Unless you've implemented a local "can" method, that's gonna be UNIVERSAL::can.

        You mean unless the superclass has implemented a local can method.

        In any case, that is of course half my point. You are correct that the SUPER::can in my original example without package statements is relative to main, which I didn't realize. But that doesn't change anything about my claim that it dispatches to UNIVERSAL::can with $_[ 0 ] as the first parameter, which I identified as the cause for the infinite loop.

        For some reason, you are saying that this reasoning is incorrect, but you haven't provided an alternative explanation. You then stated that SUPER is relative to the current package, which causes problems with code, although you made no explicit connection between the two facts.

        I still don't see how my explanation can be wrong. Assuming no local implementations of can, Bar->SUPER::can( 'foo' ) is equivalent to UNIVERSAL::can( Bar => 'foo' ), which will find Bar::foo if there is one, not the foo in a superclass of Bar, despite the adornment with SUPER:: in the wrong place. And if I'm in Bar::foo to begin with, and goto myself, that's an infinite loop.

        Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://416947]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2019-10-23 17:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?