You edited it did you? I see, shame on you. ;-)

I really don't see what advantage __PACKAGE__ has over a hardcoded class name except that it's Pythonesquely uglier.

The advantage is that using __PACKAGE__ works, whereas as written it fails the empty subclass test because of the ref $l thing

use Number::Fraction;
package Number::Fraction::Foo;
use base qw/Number::Fraction/;
1;
package Number::Fraction::Bar;
use base qw/Number::Fraction/;
1;

my $n=Number::Fraction->new(1,4);
my $f=Number::Fraction::Foo->new(1,4);
my $b=Number::Fraction::Bar->new(1,4);

print $n+$f,$/;
print $n+$b,$/;
print $f+$n,$/;
print $b+$n,$/;
print $f+$b,$/;
print $b+$f,$/;
__END__
Can't add a Number::Fraction::Foo to a Number::Fraction::Foo at D:\per
+l\devlib\/Number/Fraction.pm line 119
    Number::Fraction::add('1/4', '1/4', '') called at D:\Temp\nf.pl li
+ne 15
1/2
1/2
[download]

If you change all the ref $l's to __PACKAGE__ (As I did to create Number::FractionP) you get the expected results:

use Number::FractionP;
package Number::FractionP::Foo;
use base qw/Number::FractionP/;
1;
package Number::FractionP::Bar;
use base qw/Number::FractionP/;
1;

my $n=Number::FractionP->new(1,4);
my $f=Number::FractionP::Foo->new(1,4);
my $b=Number::FractionP::Bar->new(1,4);

print $n+$f,$/;
print $n+$b,$/;
print $f+$n,$/;
print $b+$n,$/;
print $f+$b,$/;
print $b+$f,$/;

__END__
1/2
1/2
1/2
1/2
1/2
1/2
[download]

So I'd say that ugliness has to take back seat to correctness. Pity.

:-)

---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}