>
> Keith,
> Unfortunately, this change is unlikely to be portable because it
> overrides internal Parser/Compiler methods.

The compiler is a module isn't it? (It isnt?) Perhaps it could do with  
being more modular in itself.

> Due to this, all the noble features that you wish are void.
> The job has to be done N times for N images, independently of the tool
> used, this has nothing to do with MC.
>
> You cannot ask each guy to provide an N-images compatible change, or
> set of changes, This is not practicle, and simply won't work.

You can ask him to package the core functionality separately from the  
integration functionality.

> With
> such a policy, progress will soon stop.
> Pharoers program for Pharo, squeakers for trunk, etc...

What you describe is your own personal offline development.

When you have something to offer for integration, you can publish it  
in a form that is usable.

i.e. if you publish it as a delta on a known image then it is easy to  
see what the innovation consists of.

if however you roll it into the rolling trunk without any base line,  
it becomes absorbed into the blob.

> Then, it does not prevent to exchange ideas and solutions, and it's
> better if we exchange before programming. I for sure will support
> unification on some Kernel features. But then, we can diverge,or what
> exactly is the point of having forks ?

Forking is old hat, when you can load the features you want.

Keith

>
> Nicolas
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/2dd9fd8e/attachment.htm