On 8/6/07, <b class="gmail_sendername">Andreas Raab</b> <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jason Johnson wrote:<br>> I don't personally see traits as something that comes up that often.<br>> 99% of the time inheritance, or some OO pattern gives the best<br>> solution. But in that 1% something like a trait is the correct solution
<br>> and not having it shows up a design wart.<br><br>I completely agree with this statement. And in return I *urge* you to<br>look at actual code and stand corrected ;-) Let's take an example:</blockquote><div><br>
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.
<br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Here is what the base class hierarchy in Nile looks like:<br><snip><br>So why would this be advantageous to a single inheritance hierarchy?
<br><br>I'm pretty sure someone will come back and say "but wait! isn't the idea<br>that *other* clients will use those traits and in return will be simpler<br>and better and easier?" So let's look at this too:
<br><snip><br>The structure is ... shall we say unusual and (I think) heavily<br>influenced by the desire to create permutations of existing traits<br>instead of applying other OO design principles.</blockquote><div>
<br><br>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.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The amount of added complexity is mindboggling to me, and other than<br>AbstractFileStream being a subclass of Object there doesn't seem to be
<br>*any* advantage of using traits. The disadvantages however, like the<br>explosion in the number of entities are very real (I think anyone who<br>has tried to understand the Squeak 3.9 and later meta class hierarchy<br>
will agree).<br><br>So ultimately, I agree with your statement. There may be *some* uses for<br>traits, but those are few and far inbetween (and, realistically<br>speaking, nobody has found one yet).</blockquote><div><br>
<br>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.
<br><br>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.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the cases that we have seen so<br>far, traits are simply used as MI with all the same problems that MI<br>has. Nile certainly shows the symptoms (added complexity, conflicts)<br>that we've come to recognize as the hallmark of MI systems.
<br><br>Cheers,<br> - Andreas</blockquote><div><br><br>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?
<br></div><br></div>P.S.<br><br>Just to give something concrete, here is basically what Haskell has for the Eq (equality) type class:<br><br>class Eq<br> x == y = ! (x != y)<br> x != y = ! ( x == y)<br><br>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.
<br><br>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.
<br>