in reply to Re^7: Upgrade-proofing overridden subroutines
in thread Upgrade-proofing overridden subroutines

Whoa! That's something I hadn't thought about. Thanks for bringing it to my attention. Yes, it will likely confuse people and that's probably something I should add to the docs.

Cheers,
Ovid

New address of my CGI Course.

  • Comment on Re^8: Upgrade-proofing overridden subroutines

Replies are listed 'Best First'.
Re^9: Upgrade-proofing overridden subroutines
by rir (Vicar) on Aug 18, 2006 at 01:07 UTC
    If you find a good way to explain this behaviour to folks who don't really understand aliasing and just want to "get it to work", let me know.

    I think your solution is too cute for the task. By putting such code in your codebase you endorse it for such problems; I feel this responsibility myself and I have no visibility nor reputation as a Perl expert. Since it is an approved solution, it will get used to fix the five other problem subs in Foo that featuritis may uncover. That is the tangle of interactions I would not induce.

    The way I see to make the semantics predictable is to override both Foo::foo and foo, but I haven't thought out the timing and interactions of multiple usages.

    My redefinition solution has the same weakness and should be used thusly:

    # File: My_Foo.pm use Foo; package Foo; no warnings 'redefine'; sub Foo { "redefined Foo" } 1;
    Then make any other use of Foo illegal. I'm a fan of linting code for such things during the build process.

    Be well,
    rir