Traits (Was Design best practice : put state-independent methodsonclass side?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Traits (Was Design best practice : put state-independent methodsonclass side?)

Rob Rothwell
On Tue, Mar 25, 2008 at 8:02 PM, Matthew Fulmer <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Traits (Was Design best practice : put state-independentmethodsonclass side?)

Sophie424
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" <[hidden email]> wrote in message
news:[hidden email]...

> On Tue, Mar 25, 2008 at 8:02 PM, Matthew Fulmer <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners