On 10 Mar 2010, at 16:13, Nicolas Cellier wrote:

> 2010/3/10 Bert Freudenberg <bert at freudenbergs.de>:
>> On 10.03.2010, at 14:28, Nicolas Cellier wrote:
>>>
>>>
>>> Unfortunately, this change is unlikely to be portable because it
>>> overrides internal Parser/Compiler methods.
>>
>> Not true. The Parser/Compiler changes are purely optimization.  
>> Simply look at the actual implementation of #future - it does work,  
>> just not very efficiently.
>>
>> - Bert -
>>
>
> OK optimization apart, it's just a class and two messages.
> Anyway, my point is that some kernel changes are to be done N-times,
> whatever the tool used.

Its only an example...

and you may know that it is a class and two messages but I don't. Why  
don't I  know because there is no where that it says that it is only a  
class and two messages. I don't know what it depends on and what  
depends on it either.

It could be packaged as a class and two messages then. I will do that.

> For example, when I changed TextStopConditions, I could not port
> directly to pharo, neither a changeSet, nor a MC package, because the
> two already had differences (scanSelectorAt: and others...).
> So, I just port the idea, not code, and I redo.

I am not a fan of this piecemeal approach, I guess you are kind of  
forced to do it this way because you don't have enough control of the  
host image. My preferred approach would be to make the existing module  
modular and pluggable, then replace the whole module with your better  
one. This is how I am doing the changes/sources refactoring.

> I guess it would be the same for Cuis, because Cuis does not have  
> multilingual.

Take a simpler example Cuis doesnt have styled comments or source. My  
ExporterFileOut code is written for Cuis, but pharo/squeak simply  
subclass and specialise one method to add styled text support. This  
only works if you design the module with this in mind.

So basically you have to expect to replace anything someone does with  
a non-modular mindset.

> At a certain point of divergence, that is necessary.

K