On 10/6/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,Stevan Little wrote: > On 10/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote: >> This notion of exclusionary roles is an interesting one, though. I'd >> like to hear about what kinds of situations would find this notion >> useful; but for the moment, I'll take your word that such situations >> exist and go from there. > > Well to be honest, I haven't found a real-world usage for it yet (at > least in my travels so far), but the Fortress example was this: > > trait OrganicMolecule extends Molecule > excludes { InorganicMolecule } > end > trait InorganicMolecule extends Molecule end Wouldn't that be written in Perl6 the other way around? role OrganicMolecule {...} role InorganicMolecule {...} role Molecule does OrganicMolecule ^ InorganicMolecule {...} Which is a nice usage of the xor role combinator.
Well, it does seem to accomplish a similar goal. However, in your example there is nothing about the OrganicMolecule which will prevent me from composing it with the InOrganicMolecule, which was the primary goal of the Fortress example. In addition in the Fortress example the Molecule role is not coupled to the Organic and Inorganic molecules, in your example they are. But IMHO this is just another example of TIMTOWTDI, because your example achieves similar goals and would likely be a valid design approach as well.
> And from that I could see that given a large enough set of roles you > would surely create roles which conflicted with one another on a > conceptual level rather then on a methods/attribute (i.e. - more > concrete) level. I don't abide to that. If roles are conceptually modelling the same entity their vocabulary should conflict also. Well unless some differing coding conventions accidentally produce non-conflicting roles. The whole point of type systems relies on the fact that concrete conflicts indicate conceptual ones!
But part of the power of role composability is that the role itself does not need to dictate what class it is composed into. So conceptual conflicts cannot be determined until compostion actually occurs, and conflicts between two conceptually conflicting roles cannot be detected until composition time either. And of course there is nothing to say that two conceptually conflicting roles have a concrete conflict either (either between methods or attributes). 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. 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. - Stevan
