stephane ducasse wrote:
> Andreas
> 
> You are probably right.
> May be we went too down the road.
> Now try to explain this guy that merging sophie, croquet, OLPC package 
> problems is not due to traits.

I'd say that THE major problem in trying to port Croquet to 3.9/3.10 
(which I attempted multiple times) were the changes to the class kernel 
- which are a direct result of applying traits. So I'm not sure that 
saying "it is not due to traits" is the correct way to phrase it.

Similarly for OLPC/eToys - I think the fact that the changes in the 
class kernel make projects from older versions unloadable (which IIRC 
was a well-known problem by the time 3.9 was released) may have 
something to do with it.

Cheers,
   - Andreas

> BTW I will do 3.9.1 and do something else for myself. Since yesterday I 
> discovered that I can have fun without the noise around it.
> 
> 
>>> You are correct. My issue is not as much with traits (outside of my 
>>> general prejudices about multiple inheritance ;-) but rather with the 
>>> choices that have been made with their application in the class 
>>> kernel. I've actually spent a significant amount of time trying to 
>>> understand the design and implementation decisions and my main 
>>> objection is basically the use of MI in such a mission-critical piece 
>>> of the system. From an engineering point of view one could *easily* 
>>> make a traits implementation that is a simple extension of the 3.8 
>>> kernel by subclassing for example ClassDescription. The result would 
>>> be a small, loadable(!) traits module that does not change the 
>>> fundamentals around which that kernel was built.
>>
>> Cheers,
>>  - Andreas
>>
>>
> 
> 
>