On Dec 8, 2009, at 4:08 PM, Andreas Raab wrote:

> Hi Göran -
> 
> Unbelievable. You basically just described the very idea that started this whole traits thing. When Nathanael worked with us at Disney, the traits direction came out of discussions where we wanted him to think precisely along the lines you're describing. My original thoughts on this matter was that I wanted to have something more like (biological) cells - entities that are made up of smaller things (objects), that have an inside and an outside (made up of other objects instead of abstractions like the interface/implementation distinction), that forward signals (messages) to the appropriate receptors etc.


Ted and Ian at VPRI recently wrote short notes on this topic:
http://www.vpri.org/pdf/m2009014_membrane.pdf     (Ted)
http://www.vpri.org/pdf/m2009007_COLA_kern.pdf     (Ian)

Of course, there's also Newspeak.


> What you're describing is very much in line with my thoughts at that point which also included more actor-like structures (some of which was later realized in Tweak and once I found E got an even stronger version in Croquet).


I was thinking today that it would be nice to merge Croquet's #future changes into the trunk's compiler.    It doesn't seem inappropriate to me; does anyone disagree?  

For those unaware of what I'm talking about, Croquet's compiler lets you write code like:

'anObject future foo: theArgs', which is translated at the AST level to 'anObject futureSend: #foo at: deltaMSecs args: theArgs'.   It's up to the receiver to implement that method sensibly.  Originally, Croquet had two implementors, Object and TFarRef, with quite different semantics.  The latter is the core mechanism by which Croquet distributes messages to object-replicas over the network.  At Teleplace, we've since implemented it in several more classes (although most of these are instances of one pattern, and could be unified).

A separate discussion would be whether there should be a default implementation in Object, and what it should look like.  I think that it's fine to not have a default implementation until a strong proposal is made.

Cheers,
Josh




> Cheers,
>  - Andreas
> 
> Göran Krampe wrote:
>> Hi all!
>> Andreas Raab wrote:
>>> BTW, I really don't think there is much difference between mixins and traits; all forms of MI are fairly equivalent.
>>> 
>>> Cheers,
>>>  - Andreas
>> As most of us I was also very positive when Traits first came to the scene. Now, I am a lot more jaded and think "well, sure, but are they worth it?".
>> Given Andreas' statement above - wouldn't it be *much* cooler to evolve Smalltalk along the axis of composition instead of the axis of inheritance?
>> I have always thought that having better mechanisms for delegation would be awesome, and would in most ways be much more powerful than inheritance (in whichever form).
>> For example, what if one could declare that for class Foo (having ivars x, y, z) any message that would result in a DNU would instead be "delegated" to ivar x (and then y if no lookup is found in x either).
>> This would be equivalent to tons of messages in Foo like:
>> Foo>>name
>>    ^(x respondsTo: #name) ifTrue: [x name] ifFalse: [y name]
>> (well, kinda, you get the picture - but also, taking care of x/y returning "self" in which case we probably should return the "Foo self" instead etc)
>> In many ways the mechanism I am describing is "built into" languages like self and Slate (I think).
>> IMHO the above is very useful and would allow fine grained composition similar to Traits but in a dynamic more object centric fashion.
>> regards, Göran
> 
>