On 12/13/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
Things work a little differently for required methods. When a
superrole requires a method be implemented, we (the language
designers) have a choise to make: it is illegal if the superrole
requires a method that the subroles don't implement or don't
themselves require, or it simply adds the new method to the required
list of the subroles which don't implement it.
Woah, that was a terrible passage. Let's try again. If your
declaration is "role Foo superdoes Bar".
* it is illegal to add a required method to Foo if Bar doesn't
already implement it or require it
* any required method for Foo automatically becomes a required
method for Bar, even if it wasn't there before
I think my case below is still understandable, if a little awkward.
I'm inclined to say
the former, even though it seems a little more brittle. It means that
when you are implementing a role in a class, all you have to look at
for what you need to do is the role and the roles that it includes;
you don't need to scan the entire source for superroles which
encompass the one you are implementing. That is the user-friendly way
to put it, but there is an analogous argument for independent
modularity (you don't want the definition of a new superrole to
invalidate objects that already exist).