Re: How best to "fix" a bug in a standard module?



kj <socyl@xxxxxxxxxxxxxxxxx> wrote:
I frequently run into minor bugs in modules downloaded from CPAN.

I occasionally find bugs, but more frequently I just have differences of
opinion about things, like when to use carp vs die. Or I want to make
optimizations for either speed or memory that are specific to the way I use
it and not of much general interest.

Aside from the issue of reporting the bug to the modules' maintainers,
there's still the immediate problem of fixing the bug for our own
use.

AFAIC, it is out of the question to replace the installed module
with one I have fixed.

What I frequently do for OO modules is just copy the module to somewhere
else, change the source copy, and then change the "use" statement. (But
not change the class method invocations).

So
use Foo::Bar;
my $b=new Foo::Bar;

becomes:

use FooBar;
my $b=new Foo::Bar;

(After I copy $somelib/Foo/Bar.pm to $mylib/FooBar.pm and modify the
latter, of course.) This can cause problems if other modules you are using
will load the original Foo::Bar themselves.


Therefore I have settled on just redefining
the buggy sub(s) in the calling code. For example, CGI::Carp::die
does not behave like CORE::die with respect to $@. To correct
this, I have this snippet at the beginning of my CGI script:

BEGIN {
no warnings 'redefine';
my $ccdie = \&CGI::Carp::die;
sub CGI::Carp::die {
@_ = $@ if !@_ and $@;
goto &$ccdie;
}
}

This seems to work fine, but somehow I'm not entirely comfortable
with doing something like this. What pitfalls am I overlooking?

If the underlying module gets upgraded, your fix to it may no longer be
compatible. You can confuse people who overlook your redefinition.
Neither pitfall is particularly devastating.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
.



Relevant Pages

  • Re: For vs. For Each
    ... "Gabriele G. Ponti" wrote in ... because chances are you will have fewer bugs if you use FOR EACH. ... > There are just more pitfalls with the regular FOR statement. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: For vs. For Each
    ... "Gabriele G. Ponti" wrote in ... because chances are you will have fewer bugs if you use FOR EACH. ... > There are just more pitfalls with the regular FOR statement. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: For vs. For Each
    ... "Gabriele G. Ponti" wrote in ... because chances are you will have fewer bugs if you use FOR EACH. ... > There are just more pitfalls with the regular FOR statement. ...
    (microsoft.public.dotnet.framework)
  • Re: For vs. For Each
    ... "Gabriele G. Ponti" wrote in ... because chances are you will have fewer bugs if you use FOR EACH. ... > There are just more pitfalls with the regular FOR statement. ...
    (microsoft.public.dotnet.general)