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

RE: OO inheritance in a hacker style

Thread Previous | Thread Next
Jonathan Lang
January 29, 2004 19:27
RE: OO inheritance in a hacker style
Message ID:
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

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

Jonathan "Dataweaver" Lang

Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!

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