develooper Front page | perl.perl6.language | Postings from January 2004

RE: OO inheritance in a hacker style

Thread Previous | Thread Next
Austin Hastings
January 29, 2004 11:22
RE: OO inheritance in a hacker style
Message ID:

> -----Original Message-----
> From: Jonathan Lang []
> 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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About