From: Jonathan Lang [mailto:[EMAIL PROTECTED] > 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
