From: Jonathan Lang [mailto:[EMAIL PROTECTED]
> Austin Hastings wrote:
> > 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."
>
> Or you could say that when you "exclude" a method, what you're really
> doing is hiding it from everything external to where it's declared, while
> leaving it available to be called internally. Method exclusion would be
> more like declaring a private method in C++ than actually removing it from
> the class or role. This means that a method wouldn't be provided to a
> class that C<does> its role but excludes it itself, and thus it wouldn't
> be used to satisfy the requirements of any other roles that the class
> C<does>.
Huh? If it's available to be called internally, you've got the same problem
(we were talking about conflict resolution earlier, I think) -- that you
need to know which one to call.
So you alias one (Dog::bark) to dogBark, which leaves Tree::bark as the
default "bark". This is fine.
But if you say "there ain't no bark", either we should complain that doing a
Dog or a Tree demands it, or we should catch the exception at compile or run
time. I'm in favor of the first solution -- you must provide one -- since
that seems to be more in keeping with the general "role philosophy" that
Larry's been emitting.
The notion of "I'm defining it to be {...}" is an interesting one -- you're
explicitly discussing it, so obviously you've thought about it. But it's not
there. I wonder if it wouldn't be easier to say {fail} instead?
=Austin
