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 19:48
RE: OO inheritance in a hacker style
Message ID:

> -----Original Message-----
> From: Jonathan Lang []
> Sent: Thursday, January 29, 2004 10:25 PM
> To:; Perl6 Language
> Subject: RE: OO inheritance in a hacker style
> Austin Hastings wrote:
> > Jonathan Lang wrote:
> > > 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.
> Actually, no; roles don't _need_ "suppress" or "rename" options to
> disambiguate a conflict: the priority chain of "class methods, then role
> methods, then inherited methods" provides all the tools that are
> _required_ to remove ambiguities: you merely override the conflicting role
> methods with a class method - which may explicitly call the preferred
> inherited or role method, do its own thing, or both.  This technique
> covers every benefit that exclusions and aliases provide with the sole
> exception of the ability to make a given method name unavailable.  Its
> only other potential fault vs. suppress and rename is poor Huffman
> encoding.

This is not my understanding. If I say

  role tree {
    method bark {...}

  role dog {
    method bark {...}

  class Trog
    does tree
    does dog

then there is a conflict unless an alias is declared, or unless the class
explicitly specified which method to call, or provides a combining method.

But saying

  class Trog
    does tree { forget bark() }
    does dog

makes it pretty clear what's happening.

Going further, this makes for interesting namespace manipulations:

  class Canis {
    method bark {
      print STDERR, "Error: Can't bark!";

  class Canis::Familiaris {
    method bark { $System::Audio->Play $.bark_noise; }

  # small smooth-haired breed of African origin
  # having a tightly curled tail and the inability to bark

  class Basenji {
    forget &Canis::Familiaris.bark;

  my $dog = new Basenji;
  $dog->bark;  # Error, can't bark!

> > Consider also that suppression across the board would be a valid
> > Aspect-Oriented operation. For example, adding or replacing a C<debug>
> > method. 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?
> It's been suggested that something like this could be handled by hacking
> the DISPATCH method of a class so that it throws an exception whenever
> that method gets called.  This doesn't really _remove_ the method in
> question, but it does render it unavailable (implicitly, at least).

Yes, but I don't want an exception. I want an "ignoration" -- possibly
causing the dispatcher to locate some other, less proximate, candidate


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