Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Open to debate on mixins and traits.

by stvn (Monsignor)
on Jun 02, 2004 at 19:08 UTC ( #359668=note: print w/replies, xml ) Need Help??

in reply to Open to debate on mixins and traits.

I find your terminology a bit confusing. There are Perl 6 "traits", then there are Perl 6 "Roles", which are somewhat based on the ideas in the Traits papers.

I don't really see Perl 6 traits as being all that much like Mix-ins though. Personally, I am not so sure what Perl 6 traits will be most useful for. The Apocolypse says:

A class declaration may apply various traits to the class. (A trait is a property applied at compile time.) When you apply a trait, you're accepting whatever it is that that trait does to your class, which could be pretty much anything. Traits do things to classes. Do not confuse traits with roles, which are sworn to play a subservient role to the class. Traits can do whatever they jolly well please to your class's metadata.
It sounds to me like a place where only the genius or the insane will venture (at least regularly). Either way, I am still not 100% sure what good they will provide other then to implement "deep-level" things like AOP, or to replace the "symbol-table-hacking" stuff. But I am not even sure about that, of course if anyone cares to enlighten me, it would be much appreciated.

As for Perl 6 Roles, these I feel are more akin to Mix-ins, although not quite really. From my (limited) understanding, Perl 6 Roles will really be a fancy way to set up a delegation-type relationship between classes and Roles (which I see as being partial or deffered classes). This is very different from the Traits idea it was originally based upon (which in some ways are very much like Mix-ins, just with a clear set of rules and a means to enforce them).

Confusion over terminology aside, I would like to comment on some of what you list as problems for "mixins, traits, etc":

be universally usable
I don't believe this to be true, and IMO one of the reasons why things like this get a bad wrap. Any experienced OO programmer knows that you have to know when to say when, or you end up with the God-Object-Uber-Base-Class-From-Hell. It is highly unlikely that you can create mix-ins or traits that can be all things to all classes. At some point you need to weigh the benefits of code-reuse vs. code-complexity. When it really comes down to it, polymorphism a more powerful means of code-reuse anyway.

I would recommend reading this Traits paper to see how they refactored the Smalltalk Collection hierarchy with Traits. It shows that building Traits, should not be treated as just building small, incomplete classes to be squished together at a later time, but instead a rethinking of how classes are/can be composed. Its very informative, and likely relevant to how one might use Perl 6 traits/Roles as well.

Keep in mind, that there is nothing in the Traits rulebook that says you cannot implement a Trait with no methods and only requirements (which amounts to the equivalent of a Java interface). And I would expect that Perl 6 Roles and traits works that way too.

avoid namespace clashes
Well, I imagine Perl 6 traits, being compile-time beasts, will not even allow this. Perl 6 Roles have means of working around this by fully qualifying the name. And Traits are much like Perl 6 traits in this, in that there are rules to govern namespace conflicts and they will all either be resolved at compile time, or just not compile.
Comparability and equality
There is such an instance that is identical except for the difference in their traits.
Is it the same?
I would argue that they are clearly not the same instance, but that it not to say that they are not equal to one another. Maybe I am misunderstanding you, but I see determining comparability and equality as not really having to do with the concept of "mixins and traits" and more having to do with the requirements of your specific application. For some classes equality may be their UUID, for others, it is equivilant internal data, its really all about what you want to do with it. Again, maybe I am misunderstanding you here, please correct me if I am.

In the end, all these things (Perl 6 traits, Perl 6 Roles, Traits (ala the papers)) are still toys. And much as dragonchild points out, they will be feared initially, and if they prove useful, will eventually become accepted parts of how we all code OO. Even after having written Class::Trait, I have yet to find a real good use for it, other than something to play around with. And I am waiting on either Class::Roles or Class::Role to see how Perl 6 Roles might be useful, and I suppose I will need to wait for Perl 6 itself to see how Perl 6 traits might play out.

  • Comment on Re: Open to debate on mixins and traits.

Replies are listed 'Best First'.
Re: Re: Open to debate on mixins and traits.
by BrowserUk (Pope) on Jun 02, 2004 at 20:09 UTC

    Yes. I did/do tend to mix up the terminology. When I used the word "trait", I was thinking of the Traits definition and Perl6 Roles.

    But then I threw in the :trait syntax which is wrong! But that just serves to emphasis the (my?) confusion both with the naming and the P6 differentiation, which still leave me perplexed.

    I'm still thinking about your other points. I may get back to you if I have questions arising :) Thanks.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
      But that just serves to emphasis the (my?) confusion both with the naming and the P6 differentiation, which still leave me perplexed.

      It's perfectly simple.

      We have Perl 6 traits, which are different from Self traits, both of which are different from Xerox Star traits, all three of which are different from the Traits described in traits paper - which Perl 6 will call roles. Except roles have state with the traits paper Traits don't.

      Traits (that is Perl 6 traits, not the trait paper traits, Self traits or Xerox Star traits) are roles applied to declared items like classes and containers. Unless they are applied at runtime in which case they are called properties.

      Confused? You won't be after the next episode of... Soap!

      ;-) * 0.5

      (Okay, I admit it, I've still not found the time to more than skim A12 so I may have got some of the above wrong, and there is probably a nice simple structure in there that's not managed to find its way into my head yet)

        Confused? If you aren't, you are (LW|TheDamian|deluded).

        If it wasn't so funny it would be serious:)

        Re:Soap! I'd love to see a modern remake of that. Just think what they could do with special effects and a descent budget--maybe as a movie, but then it wouldn't be a soap, unless it was a movie about a soap?)

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        Confused? You won't be after the next episode of... Soap!
        But I always felt more confused after the next episode of Soap, and I'm getting close to the same point with each next episode of /[AES]\d+/.

        I got most of A12, but every so often my eyes would just go out of focus and a minute later, 2 paragraphs down I'd wonder what I had just read.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://359668]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2021-03-01 22:04 GMT
Find Nodes?
    Voting Booth?
    My favorite kind of desktop background is:

    Results (26 votes). Check out past polls.