Thanks guys - What I really meant was than an abstract base class could perhaps be considered appropriate given that a Cookie has an isA relationship. My main point is that the trait defined doesn't lend itself to being mixed into other classes. Cookie is something that stands alone and can be considered a class.

This might help explaining where I'm coming from:

http://www.artima.com/pins1ed/traits.html#12.7

On 03/07/2013, at 3:31 PM, James Roper <notifications@github.com> wrote:

> In framework/src/play/src/main/scala/play/api/libs/ws/WS.scala:
> 
> > @@ -481,6 +482,58 @@ object WS {
> >  }
> >  
> >  /**
> > + * A WS Cookie.
> > + */
> > +class Cookie(val ahcCookie: AHCCookie) {
> As will said, it's about not exposing the underlying implementation, the goal is that we can substitute a new implementation without breaking binary compatibility, exposing a constructor that accepts NingCookie would not allow this. That said, another way would be to have a private constructor, which I just found out to do this in Scala you do:
> 
> class Foo private (val bar) {
> }
> traits have multiple purposes in Scala, one is to be an interface.
> 
> —
> Reply to this email directly or view it on GitHub.
>