HaloO, Stevan Little wrote:
I think that maybe we need to seperate the concept of roles as types and roles as partial classes, they seem to me to be in conflict with one another. And even they are not in conflict with one another, I worry they will bloat the complexity of roles usage.
The bloat aside I believe it is essential to have roles as the key players of the type system. I propose to handle the typeish aspect of roles as described in the paper I linked to: there should be a trait 'is augmented' that is applicable to a role and to methods in a role. In such a method a call to next METHOD should invoke the class's method. Alternatively we could make the method combination behavior the default and have a class method trait 'is disambig' or 'is override' for the case where the class needs to have the final word. 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.
My experiences thus far with roles in Moose have been that they can be a really powerful means of reuse. I point you towards Yuval Kogman's latest work on Class::Workflow, which is basically a loose set of roles which can be composed into a highly customizable workflow system. This is where I see the real power of roles coming into play.
Is this a set of free mixins or are they dependent on the class to provide a certain interface to fully achieve the means of the roles? I also consider roles a powerful tool but I believe that the type system should play a role in the composition process that goes beyond simple checking of name clashes. Regards, --
