Robert Dober wrote:
> On 10/15/07, Daniel Berger <djberg96 / gmail.com> wrote:
>>
>> On Oct 15, 9:38 am, Yukihiro Matsumoto <m... / ruby-lang.org> wrote:
>>> Hi,
>>>
>>> In message "Re: RubyTraits 0.1"
>>>     on Tue, 16 Oct 2007 00:23:43 +0900, Trans <transf... / gmail.com> writes:
>>>
>>> |I see. So you don't really like the fact that modules fit into the
>>> |inheritance chain? That's interesting.
>>>
>>> Actually they both have their own good.  I like them both.  I dislike
>>> to have them both in a language.  Traits injection is clear and less
>>> error prone (there's no possibility of conflicts), but sometimes
>>> method overriding is _very_ useful, where aliasing is very poor way to
>>> create method combination.
>>>
>>> If someone come to the idea to allow modules to have merits from both
>>> mixins and traits at once (without demerit), I'd love to hear.
>> I solved this "problem" over two years ago with fine grained mixins.
>> Please see http://rubyforge.org/docman/view.php/735/309/README.html
>> and look at the synopsis. Ideas (and code) in that library also came
>> from Ara Howard and Mauricio Fernandez.
>>
>> I don't want up front object composition. To me that's like static
>> typing, except for object composition. At worst, a warning should be
>> issued if a double inclusion occurs. This is what the 'use' library
>> does in verbose mode.
> If what you did solves your problem than that is good, it however does
> not address the issues that are adressed by traits.

The multi-mixin (i.e. total ordering) problem is one of the primary 
reasons for Traits, or at least, one of the main digs against mixin 
inheritence. My library solves that in a dynamic, but not strict, manner.

> And the good thing about traits is that, if you do not want to use
> them, then just do not.

As a third party library they're fine. But core? No.

> I have followed the discussion on the Squeak Mailing List before
> making traits part of the kernel. The killer argument was, ok we are
> going to do this because it will make the code base "better" but
> nobody will ever need to care about Traits unless they want.
> To be fair, Squeak needed Traits much more than Ruby as they had no Mixins.

Exactly. In languages that have no mixins I think Traits are fine and, 
from what I can gather, it's the mixin capability those languages and 
communities are really after, not the composition.

> OTOH I have never heard anybody complain that traits remind them of
> static typing, would you mind to elaborate on that Daniel?

In a couple of ways. First, raising an error if method conflicts arise 
feels too strict for a dynamic language. I'd like a warning, but nothing 
more. Also, a trait requires a set of methods that serve as parameters 
for the provided behavior. Like static typing, that means up-front 
declarations that don't mesh well with the overall philosophy of dynamic 
languages IMO.

Regards,

Dan