develooper 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 30, 2004 11:21
Subject:
RE: OO inheritance in a hacker style
Message ID:
ICELKKFHGNOHCNCCCBKFGEOJCJAA.Austin_Hastings@Yahoo.com


> -----Original Message-----
> From: Jonathan Scott Duff [mailto:duff@lighthouse.tamucc.edu]
> On Thu, Jan 29, 2004 at 10:54:18PM -0500, Austin Hastings wrote:
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:dataweaver42@yahoo.com]
> > >
> > > 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.
>
> Doesn't
>
> 	class Trog
> 	   does tree
> 	   does dog
> 	{
> 	   method bark { ... }
> 	}
>
> Also make clear what's happening?  Especially when the ... isn't
> literal, but really a call to tree.bark or dog.bark.

Not as I recall from the paper. Especially not if the methods have different
signatures. The point here being that either tree or dog may have other
methods that call C<bark> internally, so the defined interface is a required
list -- the only thing you can do is explicitly provide some sort of
behavior modification.

> > > 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.
>
> 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".

> That's not how I interpretted "forget" It looked more like "this method
> doesn't exist, please error now". Which you can achieve by providing a
> an ordinary method that just errors. However, if you wanted to control
> how the method is dispatched, that's exactly what .DISPATCH() is for.
> (assuming .DISPATCH is writ in something resembling stone as I only
> recall seeing it mentioned once or twice) Just write it so that it
> doesn't consider the multi-method you want to forget.

See above. I'm willing to believe that a module could be done that provides
this service in the way you describe, if it can be temporized.

=Austin


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About