Survey finally published etc

goran at goran at
Wed Jan 25 06:48:22 UTC 2006


Andreas Raab <andreas.raab at> wrote:
> tim Rowledge wrote:
> > Here you are expressing the major problem in a group project-
> > - You want everything else to stay the same so your massive changes  can 
> > go ahead.
> > - So does everyone else doing any work!
> > 
> > We simply can't make any useful progress under such conditions.  Forward 
> > progress causes breakage and it costs much effort to provide  invisible 
> > mogration support. Spending time on that prevents forward  progress - 
> > and puts people off ever bothering.
> I don't believe that is true in general. I agree there are some changes 
> where backward compatibility is very hard (or basically impossible) but 
> for most of the changes that's not true. Generally, I've come to opt for 
> the "parallel subsystem approach" where you don't simply destroy an 
> existing subsystem just because you can but rather create a parallel 
> hierarchy of entities so that both subsystems can be loaded side by side.
> For example, I hope that if we ever get a new set of Stream/File classes 
> they would be done in a way that the old classes could be loaded and 
> used side-by-side.

In the recent discussions in the IO team (well, on IRC anyway) that was
the idea (Flow).

> For example, I hope that if we ever get a new 
> compiler, this would be done in a way that the old compiler can be 
> loaded and used side-by-side. For example, if we ever get a new set of 
> tools, I would hope that... etc.

Another good example would be a new Collection hierarchy based on
Traits. I proposed such an approach a long time ago (building a separate
"New Collections" package) - instead of changing the current quite old
and crufty but oh so very fundamental Collection hierarchy.

And one of the reasons for that approach was the strong resistance from
some parts of our community regarding even very small and obvious
improvements (like adding a #removeAll method with efficient
implementations in the different classes) - so don't underestimate the
views of the die hard Smalltalk-conservatives in our community. ;)

And while on the subject of Traits - personally I would not start using
it in base classes until it has settled in and become an accepted and a
bit more mature part of Squeak. But as I said, no harm in using it in
*parallell* implementations, like "New Collections".

So yes, I agree with you Andreas - parallell development should be the
norm, whenever it isn't utterly impractical.

> Cheers,
>    - Andreas

Cheers, Göran

More information about the Squeak-dev mailing list