Yes, i understand and identified this problem.
But if it really is the only problem, then the easiest thing is to 
remove Trait as the first porting operation.

Not that trivial (bootstrap), but should be easier than replaying all 
3.9/3.10 changes.

Nicolas


Andreas Raab a écrit :
> 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
>>>
>>>
>>
>>
>>
> 
> 
>