[squeak-dev] Object >> future
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>:
> 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.
> 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.
But that's just facts, when I port Pharo<->Squeak, I can't always port
More information about the Squeak-dev