Brad Bowman wrote:
TSa wrote: > TSa wrote: >> Note that the superclass interface of roles should be mostly inferred >> from the usage of next METHOD. As such it is a useful guidance for >> error reports in the class composition process. > > Actually 'next METHOD' doesn't catch all superclass interface issues. > There is the simple case of calling e.g. accessor methods on super > which should result in the requirement to provide them. So I still > propose a super keyword that in roles means the object as seen from > the uncomposed class.
What do you mean by "uncomposed class"?
I think the word "super" is already to overloaded to be used for this purpose. Setting that aside for now... Do you mean that super.blah() appearing in a method defined in a role A should require that all classes which do A need to provide a blah implementation? (or produce a composition time error if they don't)
I hope not; that's exactly what declaring an unimplemented method in a role is supposed to do. (And declaring an implemented method does the same thing, with the addition that it also suggests an implementation that the class is free to use or ignore as it sees fit.)
The same applies to the "next METHOD" inference suggested: > Note that the superclass interface of roles should be mostly inferred > from the usage of next METHOD. A Role should be able to say "to do this Role you need to implement these methods" and have a compile/composition time error if not.
Agreed.
(There does need to be a way to call, in a Role A, both the "blah" defined in A and whatever the "blah" the final class may use. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.)
No, there doesn't. Given that C<class Foo does A> and C<role A does B>, There needs to be a way to call, in class Foo, both the "blah" defined in Foo, the "blah" defined in A (so that Foo can reimplement A's version as a different method or as part of its own), and the "blah" defined in B; and there needs to be a way to call, in role A, both the "blah" defined in Foo and the "blah" defined B; but role A does not need a way to explicitly call a method defined in A. It should assume that if Foo overrides A's implementation of blah, Foo knows what it's doing; by the principle of least surprise, Foo should never end up overriding A's implementation of blah only to find that the original implementation is still being used by another of the methods acquired from A. -- Jonathan "Dataweaver" Lang
