Front page | perl.perl6.language |
Postings from January 2004
RE: OO inheritance in a hacker style
Thread Previous
|
Thread Next
From:
Austin Hastings
Date:
January 29, 2004 11:22
Subject:
RE: OO inheritance in a hacker style
Message ID:
ICELKKFHGNOHCNCCCBKFAENMCJAA.Austin_Hastings@Yahoo.com
> -----Original Message-----
> From: Jonathan Lang [mailto:dataweaver42@yahoo.com]
> Sent: Thursday, January 29, 2004 1:29 AM
> To: Joseph Ryan; Dmitry Dorofeev
> Cc: Perl6 Language List
> Subject: Re: OO inheritance in a hacker style
>
>
> Joseph Ryan wrote:
>
> > Of course, roles are another great way to prevent confusion with
> > multiple inheritance. A good question would be whether something
> > like "forget" is useful in addition, or whether everyone should
> > just use roles. :)
>
> For the record, roles are not a form of multiple inheritence. They're
> similar in that both are techniques for code re-use; but there are crucial
> differences - for instance, classes call methods; roles merely provide
> methods for classes to call.
>
> How about this: allow for two approaches for calling a given method:
> implicit (state the object and the method, and leave it up to the class
> dispatcher to figure out where the method is to be found - in the class,
> one of its roles, or one of its parents) or explicit (state the object,
> the method, and the class or role where it will be found). Allow
> exclusion of inherited and role methods, but define exclusion strictly in
> terms of implicit calls: you're telling the class dispatcher to ignore
> that role or parent when searching for candidate methods to call.
>
> Explicit calls would suffer from "brittleness" - that is, if you rename a
> role or a class, you'd need to hunt down every instance where one of its
> methods is explicitly called and rename it there as well. Implicit calls,
> OTOH, would risk incompleteness - exclude an inherited or role method from
> a class without providing a valid substitute, and other code may end up
> assuming that the class has capabilities that it doesn't.
I think that both of these capabilities are already present in P5, and have
been agreed upon for P6:
$obj->foo(); # dispatches, and
Class::Subclass $obj; # explicitly invokes.
> The danger isn't really in the ability to suppress a method from a given
> role or parent; the danger comes from the ability to suppress a method
> from _every_ role or parent. A safe alternative to this would be to
> define a class method which then turns around and explicitly calls the
> inherited or role method that you really wanted; the drawback here is the
> poor Huffman encoding involved: writing a method is considerably more
> bulky than saying "exclude ..." or "rename ...". You can resolve this
> dilemma in two ways (not mutually exclusive): forbid the latter options,
> or come up with a more succinct way of handling the former option.
I don't think this is a disadvantage.
Consider that ROLES already require some similar feature: When two roles
have methods that conflict, there is a requirement to suppress or rename one
or both methods.
Consider also that suppression across the board would be a valid
Aspect-Oriented operation. For example, adding or replacing a C<debug>
method is a fairly common example. But suppressing the same debug method for
use in finished products might be advantageous, especially if it resulted in
a smaller compiled executable.
To me, the "forget" or "discard" or "dispose" or "delete" (gasp) keyword or
operation has a valid place, even if it's not a frequently used place. I
guess the question is: Could we successfully implement this in 6.1 as a
module?
=Austin
Thread Previous
|
Thread Next