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.
| [reply] |
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 ]
| [reply]
[d/l]
[select] |
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.
| [reply] |
| [reply] |
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.
| [reply] |