Re: OO inheritance in a hacker style
Joseph Ryan writes:
It's surely possible by modifying that class's DISPATCH.
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
Well, what if the two classes you want to inherit from weren't
designed with roles in mind? For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Cforget doesn't help you there. That would presumably forget Iboth
methods, leaving you with none. That doesn't sound too useful. If you
could add a SomeClass:: on the front of the method, like:
class Foo is Bar is Baz {
forget Bar::frobnicate;
}
That looks backwards. It would certainly make more sense to specify
which method you want to use, as opposed to specifying all the methods
but the one you want to use.
A syntax that is the opposite of forget -- one that lets you specify
which method to use without typing that parameter list twice -- might be
useful, but it's trivial enough to, er, forget for now. I wonder
whether it's possible to say:
class Foo is Bar is Baz {
method frobnicate := Baz::frobnicate;
}
I know my syntax there isn't right quite. :-)
Besides, the user is not thinking about XXX right sounds like we
need to give a ++ to the pythonometer ;)
Let's say someone came on here and asked how to use regexes to make a
socket connection. Surely the user is not thinking about regexes
right... or sockets.
Luke
Re: OO inheritance in a hacker style
On Wed, Feb 04, 2004 at 01:30:44AM -0500, Joseph Ryan wrote:
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
Well, what if the two classes you want to inherit from weren't
designed with roles in mind? For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Same way you do it now.
package Foo;
use base qw(This That);
sub conflicting_inherited_method {
goto {That-can(conflicting_inherited_method)};
}
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Cheating is often more efficient.
- Seven of Nine
Re: OO inheritance in a hacker style
Luke Palmer wrote: Austin Hastings writes: Hmm. The text and examples so far have been about methods and this seems to be about multi-methods. Correct me if I'm wrong ... You're wrong. Consider my example, where via single inheritance we reach a layered list of methods, each of which replaces the previous one in the namespace (parent.method superseded by child.method). This is not multi-dispatch -- the class of the object being dispatched determines the method -- but I want to modify the dispatch chain so that some upstream class' method is ignored. It's surely possible by modifying that class's DISPATCH. Whether it should actually be in the language is up for debate. I'd say that if you need to do this with any frequency whatsoever, you're not thinking about roles right. A good example might be in order... :-) Well, what if the two classes you want to inherit from weren't designed with roles in mind? For instance, there might be two CPAN modules that each have a dozen methods that you want to inherit, but they each have 1 that overlap whose conflict you want to easily resolve. Besides, the user is not thinking about XXX right sounds like we need to give a ++ to the pythonometer ;) - Joe
