Flylib.com

Books Software

 
 
 

Hack 36. Replace Bad Code from the Outside


Hack 36. Replace Bad Code from the Outside

Patch buggy modules without touching their source code.

Until computers finally decide to do what we mean, not what we say, programs will have bugs . Some you can work around. Others are severe enough that you have to modify source code.

When the bugs are in code you don't maintain and you don't have a workaround, Perl's dynamic nature can be an advantage. Instead of keeping local copies of externally managed code, sometimes patching that code from the outside is the simplest way to make your code work again.

The Hack

Imagine that you're building a large application that uses a hypothetical Parser module that, for whatever reason, calls exit( ) , not die( ) , when it fails. The relevant code might look something like:

package Parser;

sub parse
{
    my ($class, $text) = @_;
    validate_text( $shift );
    bless \$text, $class;
}

sub validate_text
{
    my $text = shift;

exit 1

unless $text =~ /^</;
}

1;

You might normally expect to use this module with code such as:

use Parser;

my $parser = eval { Parser->parse( 'some example text' ) };
die "Bad input to parser: $@\n" if $@;

However because of the exit( ) , your program will end. It may be perfectly legitimate that the text to parse in this example is invalid, so Parser can't handle it, but the exit( ) is just wrongit gives you no opportunity to alert the user or try to fix the problem. If validate_text( ) were a method, you could subclass the module and override it, but you don't have this option.

Fortunately, you can override the exit( ) keyword with a function of your own, if you do it at the right time:

package Parser;
use subs 'exit';
package main;

use Parser;
sub Parser::exit{die shift;}

Before Perl can parse the Parser package, you must tell it to consider all occurrences of exit( ) as calls to a user-defined function, not the built-in operator. That's the point of switching packages and using the subs pragma.

Back in the main package, the odd-looking subroutine declaration merely declares the actual implementation of that subroutine. Now instead of exiting, all code that calls exit( ) in Parser will throw an exception instead.

Hacking the Hack

If you don't really care about validation, if you prefer a sledgehammer solution, or if you don't want to replace exit( ) in the entire package, you can replace the entire validate_text( ) function:

use Parser; 
local *Parser::validate_text;
*Parser::validate_text = sub
{
    my $text = shift;
    die "Invalid text '$text'\n" unless $text =~ /^</;
};

Doing this in two steps avoids a warning about using a symbol name only once. Using local replaces the code only in your current dynamic scope, so any code you call from this scope will use this function instead of the old version.

To replace the subroutine globally, use Parser as normal, but remove the line that starts with local . Replace it with no warnings 'redefine'; to avoid a different warning.

If you need to switch behavior, make the replacement validate_text( ) into a closure, setting a lexical flag to determine which behavior to support. This variant technique is highly useful in testing code.



Hack 37. Drink to the CPAN

Play London.pm's CPAN Drinking Gamebut responsibly.

The CPAN drinking game tests your knowledge of the CPAN. The goal of the game, depending on who you ask, is either to prove that you have an incredibly deep knowledge of the CPAN or to get incredibly drunk. An alternate goal is to learn about modules you never even knew existed. Just try to remember them.

Running the Hack

The first player, Audrey, takes a drink and names a CPAN module: Devel::Cover . Play passes to Barbie, who's sitting immediately to Audrey's right. Barbie needs to drink and then come up with a released module which starts with C , the first letter of the last part of Audrey's module. If he can't, he drinks and play passes to the next player.

If Barbie names a module with three parts , perhaps Crypt::SSLeay::X509 , play skips over chromatic, who's sitting to his right. The same applies if he managed to pull out a module name with four, five, or more parts.

Domm picks up with X . He drinks and pulls out XML::XPath . Because the last part starts with the same letter as the first part, the direction of play reverses and it's chromatic's turn .

chromatic drinks and, sadly, can't come up with anything and has to pass. He's now out of the game. Audrey drinks and names XML::Simple . Play continues counterclockwise to Domm, who needs to come up with something starting with S .

The winner is the last remaining player.

Hacking the Hack

Try whiskey!

Seriously, as bar-rific as the game sounds, you don't have to drink alcohol. Try another beveragehot tea is good, root beer is good, and anything with caffeine can change the rule for losing in interesting ways.

Some variants of the game require Barbie to drink until he can name a module. This can take a while.

The author recommends never challenging Audrey to the CPAN drinking game.