On Fri, Jun 29, 2001 at 04:42:57PM -0400, [EMAIL PROTECTED] wrote:
> > It's also not without its faults. Having every instance of a
> > class have different values of ref() could be obnoxious, for
> > example.
>
> Why? You shouldn't be relying on an object's reference. ref $obj eq
> 'Some::Class' wrecks subclassing, $obj->isa('Some::Class') is the
> right way.
If you're relying on an overload isa() method to determine if something
belongs to a given class you're going to run into problems. Several times
I've used UNIVERSAL::isa($obj, "Some::Class") to determine if $obj is both
an object and belongs to the specified class.
I suppose you could modify UNIVERSAL::isa to forward the call on to the
class, but at that point the hack is no longer well-encapsulated.
> > No, that's a lousy rule of thumb. The tradeoffs must be considered.
> > Otherwise we'd have Forth. (Or Lisp, ca. 1960.)
>
> What's the trade-off here? It works, its efficient, the hacks are
> well encapsulated.
The reason the feature (object-level ISA) was suggested in the first place
was to solve the problem of multiple, pointless, only-there-to-set-@ISA,
classes to serve MI. How often is MI really used? Would this solution
greatly speed up MI? Would it greatly reduce the speed and memory
efficiency of the large body of OO code that doesn't use MI? These
questions really haven't been answered, nor do I think they really can be at
this point (at least, not the latter two).
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
