Still, two more questions if I may:

First of all, what happens if two roles use the same attribute? The paper pointed out traits must not have attribute to avoid diamond problem (for those who don’t know what it is and have better things to do then read overly-long papers ;) it’s situation where class A inherits from B and C and both B and C inherit from D) and here it seems as if the problem was not avoided at all.

And finally, from what I’ve understood one cannot parametrize classes. Question is: Why? For instance, a legitimate use case would be to have a “Container[::Type]” role and a “RBTree[::Type]” class which “does” the role.

As a further benefit, the different names imply something about the purpose. Sure, I can write a class with named regexes in it (albeit missing the useful built-ins that I’d inherit if I’d used the grammar keyword) and a grammar with methods in it. But that doesn’t mean having them called different things to state the difference in intent is a bad thing.

To get a better grasp of the differences between inheritance and composition, I suggest reading the original paper, which offers a much more detailed explanation:

http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf

Finally, you noted that I did use a role on its own in my last example. I guess you meant:

my Tray of Glass of MulledWine $valuable;

But here I am not using the role – just setting it as a type constraint on the variable. Any object that does that role could then be stored in $valuable.

Also “we can not use a role on its own” but if it’s a parametrized role we can use it on its own if we specify parameters (as seen in the last example). Doesn’t this inconsequence strike you?

http://use.perl.org/~JonathanWorthington/journal/38308

You’re right that the parameterization isn’t ground-breaking in itself. One difference is that we use multiple dispatch to decide between possible variants of a role based upon the arguments. Another thing that distinguishes Perl 6 from some (but not all) implementations of things like this is that arguments may be values or types. The Perl 6 standard grammar makes use of roles parameterized on values.

Hope this helps,

Jonathan

    token trait_mod:does {
        :my $*PKGDECL ::= 'role';
        <sym>:s <module_name>
    }

So at the moment you need to write “does” each time, but I guess it’d be possible to tweak the trait_mod parsing rule there to allow multiple. One issue is if people will view them as somehow “grouped”, when in reality it means nothing extra at all over writing “does”… The harder problem is that the trait mod compiles to a multi-dispatch, so we’d have to work out what happens there (I guess we’d dispatch a list of things, and the candidate that handles a list would iterate and re-dispatch on each of them). Anyway, it’s a little deeper than just a syntax change.