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

RE: Roles and Mix-ins?

Thread Previous | Thread Next
Austin Hastings
January 6, 2004 20:39
RE: Roles and Mix-ins?
Message ID:

From: Jonathan Lang []
> 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.


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