hi all

I just wanted to share the following with you. I hope that we will have 
soon a ready to use bright new
implementation of traits in Squeak.

Stef


Andrew,

Your article "Traits: Composable Units of Behaviour" was mentioned on
comp.lang.ruby this evening.  It seems very much like you were 
describing
Ruby's modules which are collections of methods and instance vars that 
can
be mixed into classes.

Just curious: I'm wondering if you've looked at the Ruby language
(http://www.ruby-lang.org)?  Ruby is a single inheritance OO language 
with
mixins. I find that in Ruby I tend to only use
inheritance very rarely and instead favor mixing  modules into classes,
adding methods to existing classes/objects (Ruby classes/objects are
always open meaning they can be extended even at runtime), or using
aggregation.  I actually can't recall the last time I used inheritance 
on
a Ruby project, and I've been developing Ruby code professionally for 
the
last three years.

Phil Tomson
Aloha, OR


Then my answer but I did not get an answer to my question

> Hi
>
> Phil sure we looked at Ruby. I bought the book when it was just out.
> Ruby seems to have a lot of stuff but often a bit hackish.
> I found a bit bad that "modules" denote something else than module in
> literate since decade means
> but this is the way it is.
>
> Traits have been designed to manage the clash that you can get when you
> compose mixins in ruby,
> to offer a good composition mechanism, In ruby the *order* of include
> defines the visibility of the included
> mixins so you can end up with problems.
>
> Something that I could not find in the book (not really a good one)
> can you in a mixin invoke an overridden method using super? One person
> told me yes but it is not a trustable source :)
>
> Another point that is not clear to me is why do we need "extend"
> the promotion of a mixin to the class level using extend seems ad-hoc.
> class SillyClass
> 	include SillyModule 	#instance Methods
> 	extend SillyModule 	#class Methods
> ...
>
>> Andrew,
>>
>> Your article "Traits: Composable Units of Behaviour" was mentioned on
>> comp.lang.ruby this evening.  It seems very much like you were
>> describing
>> Ruby's modules which are collections of methods and instance vars that
>> can
>> be mixed into classes.
>
> Not that quite. Traits are a bit more advanced ;) if they were only
> ruby modules
> this would be that we did not do our job well. Or that the reviewers of
> ECOOP were
> idiot.
>
>> Just curious: I'm wondering if you've looked at the Ruby language
> Ahh these researchers they invent stuff that already exist.
>
>> (http://www.ruby-lang.org)?
> This is the japanese site :)
>
>
>>  Ruby is a single inheritance OO language with
>> mixins. I find that in Ruby I tend to only use
>> inheritance very rarely and instead favor mixing  modules into 
>> classes,
>> adding methods to existing classes/objects (Ruby classes/objects are
>> always open meaning they can be extended even at runtime), or using
>> aggregation.
>
> Really interesting: one of the problem is that if you define mixin
> library with traits you
> should pay attention to conflict not only instance variable conflicts
> but also unintended name
> capture.
>
> Point>>setCoordinates: aPoint
> 	(self = aPoint) ifTrue: [^ self].
> 	self x: aPoint x.
> 	self y: aPoint y.
> 	self changed.
>
> Point>>= aPoint
> 	^ (self hash = aPoint hash and: [self x = aPoint x]...)
>
> Then another mixin
> we introduce color and redefine = to handle color too
>
> Point>>= aPoint
> 	^ (self hash = aPoint hash and: [self x = aPoint x]...) and: [self
> color = aPoint color]
>
> Now setCoordinates will propagate changed just if the point changes its
> color and not its position.
> Note that = in the second mixin can really make sense but only within
> the context of this mixin.
> Still it is impacting the other one.
>
> So the problem is that while composing a class with various mixin you
> can have method name capture
> and the solution is not to say to use another name because normally
> mixins may be shipped by other people
> only available in binary format....
>
> How do you solve this problem in Ruby?
>
> Then I would like to know for example
> 	- the average size of your mixins in terms of methods and inv
> 	- the number of mixins your class use.
> 	
> Stef
>