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.
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'd prefer to have a declarative mechanism for specifying such requirements.
Firstly for self-documenting clarity, there's no need to scan for a "super",
and secondly because eval and super.$method_name would allow runtime failures.
Some alternatives appeared elsewhere in this thread but it's unclear whether
they would produce error at composition time or at runtime. (yada methods)
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.
(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.)
Brad
--
When one is not capable of true intelligence, it is good to consult with
someone of good sense. -- Hagakure http://bereft.net/hagakure/
