I apologize--I feel like I took your question too concretely, that I missed a modest mentoring tone in your first post, and that I provoked you to the defense of your module. You tossed out Module::Build as if it were germane when we were talking about neglected modules. That seemed red-herringish to me; did I miss a point?
If you fork privately, you have to maintain it in-house.
The wisdom I was trying to share:
Adrianh's solution, if usable, has the advantage of clarity.
For readability and lack of any downside of which I can think, my first choice for an outside patch would be to redefine the problem.
use Foo; package Foo; { no warnings "redefine"; sub foo { 'different foo' } } package resume_former_namespace; ...
I like the idea of aliasing away the problem but I can see how that could be very confusing to those year-later-and-you're-gone maintainers. It is not really possible to predict what semantics those folk will expect. Should foo or Foo::foo be overridden in below? I'd avoid that issue unless I need the flexibility.
Be well,
rir
File Foo.pm#!/usr/bin/perl use warnings; use strict; use Foo; use Sub::Override; sub fixed_foo { "I'm overridden foo" } my $override = Sub::Override->new; $override->replace( 'Foo::foo' => \&fixed_foo ); # maybe 'foo' print "Foo::Ridden: ", Foo::foo(), $/; print "Foo::Ridden: ", Foo::bar, $/; print " ::Ridden: ", foo(), $/; $override->restore; print " ::Orig: ", foo(), $/;
Output of above code overriding Foo::foo.package Foo; use Exporter; our @ISA = 'Exporter'; our @EXPORT = qw/ foo bar /; sub foo { "I'm foo" } sub bar { foo() . 'bar' } 1;
Results of same code overriding foo.Foo::Ridden: I'm overridden foo Foo::Ridden: I'm overridden foobar ::Ridden: I'm foo ::Orig: I'm foo
~Foo::Ridden: I'm foo Foo::Ridden: I'm foobar ::Ridden: I'm overridden foo ::Orig: I'm foo
In reply to Re^7: Upgrade-proofing overridden subroutines
by rir
in thread Upgrade-proofing overridden subroutines
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |