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).
Luke
