in reply to Re: Informal Poll: why aren't you using traits?
in thread Informal Poll: why aren't you using traits?

Care to elaborate? It sounds interesting.

I am not sure that I would classify Traits as being "decorators" either since "decorators" usually imply some kind of delegation to other instances. Trait's are not classes at all, and cannot be instantiated. Traits actually are "flattened" into the class, so that the methods of the trait become methods of the class. The difference may seem subtle, but it greatly affects how elements of the object model can interact.

-stvn
  • Comment on Re^2: Informal Poll: why aren't you using traits?

Replies are listed 'Best First'.
Re^3: Informal Poll: why aren't you using traits?
by halley (Prior) on Nov 19, 2005 at 03:35 UTC
    My object model for simulations uses decorators but treats them as if they were melted into the base instance, so syntactically they are more like traits. Also, any particular trait/decorator type manages its own index of all living instances with that trait, for some interesting searches. But they're traits which can be attached and detached at will. I call them 'qualities' but that's just my jargon.

    Writing a simulation library with this linguistic feature has a completely different feel to it. The job is more about writing many orthogonal qualities, and using classes just as handy pre-packaged combinations of qualities. If classes are nouns, then qualities are like adjectives. I call it quality-oriented programming.

    For example, let's take a "MUD" style simulation (though I've used this for other types of sims):

    quality Living; // has a life force quality Anatomical; // has a collection of body parts quality Breathing; // has limited range outside atmosphere quality Mortal; // can die quality Injurable; // can be wounded quality Motivated; // has goals // ... and so on class Item; class Thing is a Massive Palpable Item; class Lifeform is a Living Anatomical Thing; class Animal is a Breathing Mortal Injurable Motivated Emotional Gendered Lifeform; class Mammal is a Visible Viewing Eating Drinking Listening Smelling Smelly Feeling Animal; class Primate is a Wearing Manipulating Gestural Facial Wielding Mammal; class Human is a Sentient Carrying Talking Skilled Primate;

    Note here that the qualities carry ALL of the implementation and the class definitions are completely nil. These nil classes just indicate the list of qualities to be attached upon instantiation. Also, there's no problem with removing Vocal from a particularly pesky individual Human for a while, even if she were instantiated with that quality.

    I've implemented this mechanism in C++, Java and pure Perl; the pure-perl implementation has the highest overhead of course, but I find it the nicest overall language for developing custom object models.

    --
    [ e d @ h a l l e y . c c ]

      the pure-perl implementation has the highest overhead of course, but I find it the nicest overall language for developing custom object models.

      I second that notion, Perl 5 is an excellent language for mucking about with object models. :)

      Any chance this model will be released to CPAN, or at least just open source? I would be very interested in seeing it.

      -stvn
        Any chance this model will be released to CPAN?

        Yes, eventually. Maybe even a book, as the concept of quality-oriented programming is only one of the weird non-traditional elements to my programming model. The issues here are completeness and performance analysis. I also want to release it with a useful and illustrative mini-library to help people get up to speed with the new concept.

        --
        [ e d @ h a l l e y . c c ]

Re^3: Informal Poll: why aren't you using traits?
by Ovid (Cardinal) on Nov 18, 2005 at 23:02 UTC

    Not to mention the fact that it can be a nice performance boost and you can query the class to find out what traits/roles it implements.

    Cheers,
    Ovid

    New address of my CGI Course.

      I would say that I had not heard of traits though I remember somewhere a mention of roles in perl 6. While reading the first few posts, a question formed in my mind "How are roles/traits different to interfaces?". Indeed your language in this post convinced me to post this.

      ...you can query the class to find out what traits/roles it implements.
        "How are roles/traits different to interfaces?"

        An interface (in the Java sense) has no implementation, it is only a "signature" which the consumer of the interface promises to conform to.

        Roles/Traits are allowed to have implementations. The methods in a trait are "flattened" into the consuming class. This is not all that different from just "exporting" methods from the trait's namespace into the classes namespace, except that there are a set of "rules" and "guidelines" set out in the Traits papers (see the SEE ALSO section of Class::Trait for some good links). These rules and guidelines actually make it so that Trait ordering is irrelevant, which right there removes a lot of the issues normally associated with MI and mix-ins.

        -stvn