[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project]
[ANN] Pharo MIT license clean)
Göran Krampe
goran at krampe.se
Mon Jun 29 00:27:54 UTC 2009
Hi guys!
Bernhard Pieber wrote:
>> If those words didn't convinced you that maintaining & developing a
>> bloated images, instead of separate, well defined modules is road to
>> void, then nothing else can.
> I am afraid you did not convince me. I do think that maintaining a full
> image is better.
Please note the huge amount of packages available on SM, SS etc. I am
not sure who were around at the time, but one REAL problem back then was
that if you did NOT make it into the image - you were left on the cold
outside and had to manually maintain your addon package.
But wait... so, ok, if you DID get (your package) into the image then
SqC at the time spent some of that time *for you* since they could
relatively easily see if they broke something (class refs, senders of,
implementors of etc). And hey, they could just try to run it too :)
But they ran a rather small kitchen.
Now, let's imagine putting all of SS/SM into a super mother of a
kitchen. Lots and lots and lots of packages. Some conflicting with each
other (oops), some really hard to understand, some left for dead by
their original authors etc etc.
It just won't fly. Better IMHO to make it easy to live outside the image by:
- Use unit tests. If you are green, you are green.
- Get good build and delivery tools. We have a bunch and more to come.
- Get more advanced tools for managing code between images. DeltaStreams
is one try on that.
- Perhaps even add some database to the mix for global
senders/implementors/class refs!
Anyway, all this has been said already. I am sorry, I really don't
believe in the kitchen sink UNLESS you have a specifically targeted image.
regards, Göran
More information about the Squeak-dev
mailing list
|