> -----Original Message-----
> From: Jonathan Lang [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 29, 2004 10:25 PM
> To: [EMAIL PROTECTED]; 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
method.
=Austin
