I compare a trait to a superclass, in that it can provide implemented methods, and require (i.e. like template method hooks or callbacks) other "expected" methods in the class that uses that trait e.g. any state a trait expects would have some expected accessors.
In your example you could use PetTraits with any class that implemented #foodRequirements, not just Dog or Rock subclasses.
You can also re-name (actually, alias) provided methods when you use a trait; you cannot (currently) re-name the required methods which is often useful http://www.nabble.com/A-Traits-question-td15484148.html#a15600165 and I would use them a lot more if I could do this kind of re-naming.
- Sophie
"Rob Rothwell" r.j.rothwell@gmail.com wrote in message news:22f158f00803251855h3f9e1bbenf370cb5c4b2bffbc@mail.gmail.com...
On Tue, Mar 25, 2008 at 8:02 PM, Matthew Fulmer tapplek@gmail.com wrote:
No. Traits are units of behavior that can be shared among objects.
So...if in a general sense a trait has no knowledge of the object it will be attached to, is it common practice to create traits to be used only by a specific group of objects so that some common behaviour can be assumed?
Or at that point are you just creating a subclass and should just go ahead and duplicate the methods?
As a trivial example, say you have Dog and Rock, and you want to make a Pet out of both of them even though they both have different base classes (like Animal or Mineral). Furthermore, Pet>>careInstructions needs to use "self foodRequirements," which you may provide for a Dog or a Rock, but not for all objects.
In other words, would you expect to see PetTraits that are meant to be used with Dog or Rock subclasses only?
Thanks!
Rob
--------------------------------------------------------------------------------
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners