On 8/6/07, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> Jason Johnson wrote:
> > I don't personally see traits as something that comes up that often.
> > 99% of the time inheritance, or some OO pattern gives the best
> > solution.  But in that 1% something like a trait is the correct solution
> > and not having it shows up a design wart.
>
> I completely agree with this statement. And in return I *urge* you to
> look at actual code and stand corrected ;-) Let's take an example:


Well, I don't recall endorsing Nile itself (since I haven't looked at the
code yet), nor saying that traits can't be abused. :)  In Haskell it is
possible to use Type classes to create single inheritance (albeit compile
time only) or even MI, but that's not what type classes are for.

Likewise it is certainly possible to do MI with traits, but this is IMO not
the itch they best scratch.  So if I had said explicitly or seemed to imply
otherwise then I do indeed stand corrected and apologize for misrepresenting
myself.  Any useful feature can be abused.

Here is what the base class hierarchy in Nile looks like:
> <snip>
> So why would this be advantageous to a single inheritance hierarchy?
>
> I'm pretty sure someone will come back and say "but wait! isn't the idea
> that *other* clients will use those traits and in return will be simpler
> and better and easier?" So let's look at this too:
> <snip>
> The structure is ... shall we say unusual and (I think) heavily
> influenced by the desire to create permutations of existing traits
> instead of applying other OO design principles.



Oh my, this does strike me as more complicated then necessary (though I
still need to look at the code).  But if it is as you suggest (as it may
well be), then I think something like this comes about by the constant
innuendo that traits are a solution looking for a problem.  Under that kind
of pressure one might start looking for a place to force the solution in,
unfortunately appearing to be a self fulfilled prophecy.


The amount of added complexity is mindboggling to me, and other than
> AbstractFileStream being a subclass of Object there doesn't seem to be
> *any* advantage of using traits. The disadvantages however, like the
> explosion in the number of entities are very real (I think anyone who
> has tried to understand the Squeak 3.9 and later meta class hierarchy
> will agree).
>
> So ultimately, I agree with your statement. There may be *some* uses for
> traits, but those are few and far inbetween (and, realistically
> speaking, nobody has found one yet).



With this part I still disagree.  I think I have found one:  Magnitude.  I
think that should be a trait not a class.  But to your point that is the
singular case of an obvious trait that I can think of in my whole Squeak
image.  But it *is* still useful in that context.

Personally, I think the best tact to take to *prove* traits is to go look at
how Haskell uses Type classes.  That is the best example I have seen in
using this concept.


In the cases that we have seen so
> far, traits are simply used as MI with all the same problems that MI
> has. Nile certainly shows the symptoms (added complexity, conflicts)
> that we've come to recognize as the hallmark of MI systems.
>
> Cheers,
>    - Andreas



That is a shame, but you seem to agree that the concept does have value at
least conceptually.  So I guess the question is, is this a concept that is
just getting a bad rap by what appear to be solutions made more complicated
by it's use, or is this something simply too complicated for anyone to use
correctly regardless of it's conceptual value?

P.S.

Just to give something concrete, here is basically what Haskell has for the
Eq (equality) type class:

class Eq
  x == y = ! (x != y)
  x != y = ! ( x == y)

So what this is saying is that objects that are of type Eq have the == and
!= functions.  It also provides default implementations for this, but
notice: these implementations are defined from each other.  No, this wont
compile.  But what this will do is allow you to just define the function
that is easiest and the other definition will be correct then.

So in this case you can't just declare your new type as Eq and everything
works (though you can say it derives from it, but that's something
different).  You still have to define at least one function and I think most
if not all the Type classes behave like this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070806/c24a1eca/attachment.htm