On 10/2/06, Brad Bowman <[EMAIL PROTECTED]> wrote:
Sam Vilain wrote:
> TSa wrote:
>> is this subject not of interest? I just wanted to start a
>> discussion about the class composition process and how a
>> role designer can require the class to provide an equal
>> method and then augment it to achieve the correct behavior.
>> Contrast that with the need to do the same in every class
>> that gets the equal method composed into if the role doesn't
>> have a superclass interface as described in the article.
>>
>
> This will be the same as requiring that a class implements a method,
> except the method's name is infix:<==>(::T $self: T $other) or some such.
How does a Role require that the target class implement a method (or
do another Role)?
IIRC, it simply needs to provide a method stub, like so:
method bar { ... }
This will tell the class composer that this method must be created
before everything is finished.
Does the "class GenSquare does GenEqual does GenPointMixin" line imply
an ordering of class composition? This would seem to be required for
the super.equal hand-wave to work but part of the Traits Paper goodness
came from avoiding an ordering. Composition is just order insensitive
flattening. Conflicts like the equal method in the OP have to be
explicitly resolved in the target class, either using aliases
or fully qualified names. So there's no super needed.
The "super" in a Role should be late bound, so will have no relevance
when inside the role, but only make sense when composed into a class.
This is probably one of the more confusing points of roles I think.
As for how the example in the OP might work, I would suspect that
"super" would not be what we are looking for here, but instead a
variant of "next METHOD". However, even with that an ordering of some
kind is implied.
I suppose this is again where the different concepts of classes are
roles can get very sticky. I have always look at roles, once composed
into the class, as no longer needing to exist. In fact, if it weren't
for the idea of runtime role compostion and runtime role
introspection, I would say that roles themselves could be garbage
collected at the end of the compile time cycle.
I would like a way to make one Role to require that the target class
"does" another abstract Role, is there already such a technique?
I am not familiar with one, but I have had this need as well lately in
using Moose roles. We have a concept in Moose (stolen from the
Fortress language) where a particular role can exclude the use of
another role, but not the ability to require it, although I see no
reason why it couldn't be done.
- Stevan
