[squeak-dev] Object >> future

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 10 16:16:49 UTC 2010


2010/3/10 keith <keith_hodges at yahoo.co.uk>:
>
> 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
>

Agree,
But that's just facts, when I port Pharo<->Squeak, I can't always port
source code.

> Nicolas
>
>
>
>
>
>



More information about the Squeak-dev mailing list