Hi jason

I'm not connected (just in a slooooow train lost in the country side  
of the Alps)

> In my conversations with Andreas, I always used Magnitude as the prime
> "obvious use case" example for Traits, but that turns out this
> actually doesn't work very well for the reasons laid out here:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007- 
> September/120256.html
>
> Stephane, you might consider the things in that mail when you write
> the tools, i.e. make some tools with the idea that making objects can
> consist largely of dropping traits or even trait composition
> "templates" onto a class to define it.

Yes this would be interesting.

> Andreas, you mentioned a lot of extra complexity created by Traits (in
> Proto and so).  Is this due to the implementation of Traits themselves
> or a place where someone tried to show "value" with some refactorings
> that made things worse?

I think that the kernel is not worse (but tools are lacking to  
navigate).
This is due to:
	- the fact that we could not change totally the class (for example  
you cannot change Behavior).
	- the tools does not help navigating the code (this is difficult to  
introduce another navigation axe).
	- this was difficult to identify traits in existing code (because  
sometimes the code is not that nicely organized).

I think that Nile is a good example of using traits (after we can  
discuss if ReadWriteStream and ReadStream suck or not)
Traits are like first class protocol that can be shared and we do not  
get a nice way to navigate them.


> If it is the latter, then I had a plan of removing these refactoring
> and restarting with the goals defined in the email above.  My plate is
> full and overflowing, but I could farm this task out.

Have a look at Nile and comment it. I would like to redo the same  
with the collections.
restarting test first from scratch.

Stef

>
> On 10/23/07, Colin Putney <cputney at wiresong.ca> wrote:
>>
>>
>> On Oct 22, 2007, at 2:44 PM, Ramon Leon wrote:
>>
>>
>> Ruby's modules don't allow this level of control.  Given modules with
>>
>> conflicting methods, you either get all from one or all from the  
>> other
>>
>> depending on the order you include them.  That is my understanding  
>> anyway.
>> Ramon is basically correct - the difference is in the way the  
>> conflicts are
>> resolved. If a method is defined in more than one place, which one  
>> is used?
>>
>> Ruby's modules work by inserting the module into the superclass  
>> chain. The
>> order that modules are included is the order they're inserted, so by
>> including module later in the sequence you can override earlier  
>> modules the
>> same way a subclass can override a superclass. For example, the  
>> following
>> script prints "a A":
>>
>> module Uppercase
>>  def alpha
>>  'A'
>>  end
>> end
>>
>> module Lowercase
>>   def alpha
>>     'a'
>>   end
>> end
>>
>>
>> class Upperfirst
>>   include Uppercase
>>   include Lowercase
>> end
>>
>> class Uppersecond
>>   include Lowercase
>>   include Uppercase
>> end
>>
>> first = Upperfirst.new
>> second = Uppersecond.new
>>
>> puts "#{first.alpha} #{second.alpha}"
>>
>> Traits, on the other hand works by adding the methods directly  
>> into the
>> class's method dictionary. It can't rely on inheritance to resolve
>> conflicts, so it provides ways of explicitly resolving conflicts,  
>> as Ramon
>> explained.
>>
>> Colin
>>
>>
>>
>
>