in reply to Re^2: Error handling in chained method calls
in thread Error handling in chained method calls

Hm. I'm pretty sure that Perl already does method caching, so adding your own would be redundant.

But mostly, why? There's no good reason to test this, as there's nothing better you can do that fail anyway. So what would be the point of adding all the complexity, when all you can do if you do detect a problem is fail anyway. Its just pointless.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy
  • Comment on Re^3: Error handling in chained method calls

Replies are listed 'Best First'.
Re^4: Error handling in chained method calls
by LanX (Saint) on Oct 24, 2010 at 18:38 UTC
    > Hm. I'm pretty sure that Perl already does method caching, so adding your own would be redundant.

    I wonder how. Perl would either need to be informed in advance that the methods are immutable or monitor the complete inheritance chain for new methods.¹

    But I haven't done any benchmarks yet ... IMHO there should be a notable performance gain.

    > But mostly, why?

    Well ask Gabor... I can only speculate that he wants to gather more detailed debug informations.

    ATM I can say more about the how than the why.

    Cheers Rolf

    1) of course I would appreciate to learn more about a nifty mechanism to improve performance...

      Perl caches methods. It recalculates them on every modification of (any) @ISA. At least I think that what happens for example in RT 62341 against parent.pm for example.

      I wonder how.

      From: perlapi:

      gv_fetchmeth

      Returns the glob with the given name and a defined subroutine or NULL . The glob lives in the given stash , or in the stashes accessible via @ISA and UNIVERSAL::.

      The argument level should be either 0 or -1. If level==0 , as a side-effect creates a glob with the given name in the given stash which in the case of success contains an alias for the subroutine, and sets up caching info for this glob.

      This function grants "SUPER" token as a postfix of the stash name. The GV returned from gv_fetchmeth may be a method cache entry, which is not visible to Perl code. So when calling call_sv , you should not use the GV directly; instead, you should use the method's CV, which can be obtained from the GV with the GvCV macro.

      See also mro::invalidate_all_method_caches()


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Wow, I'm impressed.

        An idealized benchmark shows only a 25% gain by memoizing, so I agree, it doesn't worth it.

        Rate classic memoized classic 75415/s -- -19% memoized 93110/s 23% --

        Cheers Rolf