HaloO,
Jonathan Lang wrote:
What do you mean by "uncomposed class"?
The self always refers to the object as instance of the composed
class. Methods are therefore resolving to the outcome of the
composition process. But super in a role refers to methods from
the class definition even when the final method comes from method
combination in the composition process.
I think the word "super" is already to overloaded to be used for
this purpose. Setting that aside for now...
Better ideas? Is there a super keyword already? Or do you mean
overloaded in general OO and type speak?
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)
Yes, this is exactly what I mean with superclass interface of roles.
I hope not; that's exactly what declaring an unimplemented method in
a role is supposed to do.
My idea is that the type system calculates a type bound for the class
from the definition of the role. That includes attributes and their
accessor methods. It's a matter of taste how explicit this interface
is declared or how much of it is infered.
(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.)
We have a priority conflict here. The question is if the class or the
role is seeing the other's methods for method combination.
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.
I agree as well. But on a wider scope then just method provision.
(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.
Yes, this is the subject of the current debate. I'm opting for a
method combination semantics that allows the role to call the class
method.
$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;
From the class all composed parts are available through namespace
qualified names. But a role is a classless and instanceless entity.
The self refers to the objects created from the composed class. The role
is not relevant in method dispatch. That is a method is never dispatched
to a role. But the role should be able to participate in the method
definition of the composed class.
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.
I'm not sure if I get this right. But as I said above a role can not
be dispatched to. Which method do you think should take precedence
the role's or the class's? That is who is the defining entity in the
method combination process? I would hope it is the role if a as of now
unknown syntax has declared it. Perhaps it should be even the default.
The rational for my claim is that a role is composed several times
and then every class doing the role automatically gets the correct
version. Otherwise all classes are burdened with caring for the role's
part in the method.
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.
Could you make an example because I don't understand what you mean with
original implementation and how that would be used by role methods.
Method dispatch is on the class never on the role. As far as dispatch is
concerned the role is flattend out. But the question is how the class's
method is composed in the first place.
Regards,
--
