Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

djberg96 (2603)

djberg96
  (email not shown publicly)

Journal of djberg96 (2603)

Saturday February 14, 2004
07:25 PM

More on "traits"

[ #17423 ]
I read Ovid's journal recently about "traits". I hadn't heard of this concept before, nor had I heard it discussed on the Ruby mailing list, so I posted it to see what people thought about it.

A guy named David Naseby wrote an interesting response. Although an interesting topic, I think Ruby's modules/mixins do just fine without the need for traits, though traits are possible to implement if you *really* need them. I think this paragraph summed things up nicely:

... I'm still not sold on the Traits concept. I'm not sure that sprinkling methods over a distributed set of Mixins would be fun to maintain, on a large scale. The Squeak implementation took advantage of the browser: you only ever see one method at a time in Squeak (smalltalk) code, anyway, and if the browser integrates with Traits, you could view and edit the methods as "part" of the class anyway. With Ruby, without a great IDE, you'd need to flick across files and use a bit of imagination to get a good "view" of your composed class - to even see what methods it's composed of. I believe that traits lose a good deal of their appeal without the Smalltalk browser, or a great Trait-aware IDE.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Actually they are a lighter and slightly less evil magic than multiple inheritance, but they are nonetheless designed solely to work around the limitations of a language rather than being useful in themselves.

    Like much of the recently touted programming paradigms - it is only required when you are stuck in the Java or C# cage and require the flexibility of dynamic languages like perl or ruby or LISP.

    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;