Front page | perl.perl6.language |
Postings from January 2004
RE: Roles and Mix-ins?
Thread Previous
|
Thread Next
From:
Austin Hastings
Date:
January 6, 2004 20:39
Subject:
RE: Roles and Mix-ins?
Message ID:
ICELKKFHGNOHCNCCCBKFIEDLCJAA.Austin_Hastings@Yahoo.com
From: Jonathan Lang [mailto:dataweaver42@yahoo.com]
> Luke Palmer wrote:
> > Renaming methods defeats the purpose of roles. Roles are like
> > interfaces inside-out. They guarantee a set of methods -- an interface
> > -- except they provide the implementation to (in terms of other,
> > required methods). Renaming the method destroys the interface
> > compatibility.
>
> Not so. A role is more than an inside-out interface; it guarantees a set
> of methods either by calling it an error to not define a given method in a
> class that C<does> the role or by defining the method itself. In the
> latter case, renaming the method can be quite useful; even in the former
> case, renaming or excluding methods from a role is useful if you want an
> interface which is almost, but not quite, like the one that the role
> provides.
There's two ways to look at that. One way is to say: "I'm going to define an
interface as being this OTHER thing minus a method." That seems like a
positive construction, and supporting it might be desirable.
The other way is to say: "Nobody knows what methods call what other methods
in their implementation (nor should we know). Therefore, removing methods is
forbidden. If you have a conflict of methods, alias them and provide support
in the knowledge that any component C<role> that requires the method may
call it internally."
I'm in favor of the second approach, myself. If you alias away all of the
(e.g.) C<bark> methods, you must provide a replacement.
=Austin
Thread Previous
|
Thread Next