Re: if (UNIVERSAL::isa($r, ref $l))

If you feel a desire to hardcode the current package, use __PACKAGE__ instead. That can be right for many occasions.

Another interesting thing though is that

  $a + $b
[download]

can work, while

  $b + $a
[download]

might not. This is quite unfortunate. $b might "bea" $a, but unless they're of the same class, $a won't "bea" $b.

Neither I see why you'd require anything more from the objects than them to be a derivate of the current class if you allow them to be of different classes already. But then again, I've never claimed to be especially enlightened when it comes to OO programming. I have a bad feeling about this though.

ihb

Comment on Re: if (UNIVERSAL::isa($r, ref $l)) Select or Download Code

Replies are listed 'Best First'.
Re: Re: if (UNIVERSAL::isa($r, ref $l)) by demerphq (Chancellor) on Jul 24, 2003 at 00:11 UTC
Regarding the `$a + $b` vs `$b + $a` issue... Overload handles this transparently. Lets say that $a is a Number::Fraction and leave $b alone for moment. If we say `$c = $a + $b` this will be magically transformed to `$c=$a->add($b,0);` But when we say `$c= $b + $a` there is only one circumstance where it will not get transformed to `$c=$a->add($b,1)` and thats when $b is both blessed, and has also overriden addition itself. In the latter case it gets transformed into `$b->add($a,0)` assuming of course the method in the other package is called 'add' as well. This is quite unfortunate. $b might "bea" $a, but unless they're of the same class, $a won't "bea" $b. The point of this node is to show that unless $b is also overriden your comment cant be true. And if $b is overriden then it had better have its own logic to handle the situation properly. I do however agree with you and the OP that there is a problem here with inheriting the add method. It just wont work right in the child classes. But unless davorg had inheritance in mind I dont think its entirely wrong. Mostly maybe.... --- demerphq _{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: if (UNIVERSAL::isa($r, ref $l))
by demerphq (Chancellor) on Jul 24, 2003 at 00:11 UTC

Regarding the $a + $b vs $b + $a issue... Overload handles this transparently.

Lets say that $a is a Number::Fraction and leave $b alone for moment. If we say $c = $a + $b this will be magically transformed to $c=$a->add($b,0); But when we say $c= $b + $a there is only one circumstance where it will not get transformed to $c=$a->add($b,1) and thats when $b is both blessed, and has also overriden addition itself. In the latter case it gets transformed into $b->add($a,0) assuming of course the method in the other package is called 'add' as well.

This is quite unfortunate. $b might "bea" $a, but unless they're of the same class, $a won't "bea" $b.

The point of this node is to show that unless $b is also overriden your comment cant be true. And if $b is overriden then it had better have its own logic to handle the situation properly.

I do however agree with you and the OP that there is a problem here with inheriting the add method. It just wont work right in the child classes. But unless davorg had inheritance in mind I dont think its entirely wrong. Mostly maybe....

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

[reply]
[d/l]
[select]