SmalltalkImage current

Norbert Hartl norbert at
Fri Jun 29 08:28:00 UTC 2007

On Fri, 2007-06-29 at 01:04 -0700, Andreas Raab wrote:
> stephane ducasse wrote:
> > you can find the complete motivation in the archives but in a nutshell 
> > the point
> > was that Smalltalk is a namespace and that over time it agglomerates
> > a lot of extra behavior (sometimes junk) that has nothing to do with 
> > namespace management.
> Of course the other way to look at it (which is more in line with 
> reality) is that Smalltalk is a representative for the environment and 
> as such includes both a name space and a set of attributes and methods 
> that relate to system-wide behavior. Such as platform information, vm 
> parameters, GC settings, startup/shutdown lists etc. which may be 
> delegated to particular places which implement them but where the 
> "natural" home (the place where the writers of the code wanted it to be 
> found) is in Smalltalk.
> That was the prevalent opinion before the cleansing jihads started. At 
> the end of which we are in my opinion in a worse state than where things 
> started: More (and duplicated) code instead of less, no improvements in 
> clarity or understanding (it's just one utility class replaced by 
> another, more obscurely named one), depracation warnings and porting 
> woes. And for what benefit exactly? Saying "SmalltalkImage current 
> platformName" instead of "Smalltalk platformName"? I really urge people 
> to go back to 3.4 and compare Smalltalk back then with Smalltalk + 
> SmalltalkImage today to see if the price is worth paying.
> I eventually got so tired about the whole mess that was left behind that 
> in Croquet I simply moved everything back from SmalltalkImage to 
> Smalltalk and only left delegation stubs in SmalltalkImage. So that if 
> you want to type your fingers bloody saying "SmalltalkImage current 
> platformName" be my guest; but really I won't make you. And it will be 
> compatible with other versions (except of course the latest 
> versions but that's not my choice to make).
Ok, now I have a picture of what it was all about. I understand your
point and like to fully agree. Except for the point of delegating back
from SmalltalkImage to Smalltalk. Cleaning is an important point. 
Cleaning at the cost of usability is not. I can imagine that it is good
to move implementation from Smalltalk to another place. I can also
imagine that there be more classes than just SmalltalkImage to keep
moved functionality. But then why it wasn't agreed to

- move implementation to the place where they are kept best
- delegate the functionalities from Smalltalk to there respective place

In my opinion that would be the best of both worls. Even if 
SmalltalkImage would be a very great idea it would have been useful to
have a transition phase where the functionality is still reachable from
Smalltalk while the cleaning team has time to fiddle the right contruct
in the back.

For me it sounds sad that it led to a state of the image which is behind
a former status quo (I can't judge with my knowledge). And it doesn't
seem there are tensions to solve it in the near future. 

I would opt for the sake of not breaking too much software that there 
should be delegating message from Smalltalk to the SmalltalkImage ones.


More information about the Squeak-dev mailing list