[UPDATES] 34 for Squeak3.7alpha AND TESTS!!!!

Markus Gaelli gaelli at emergent.de
Sat Jan 17 19:57:18 UTC 2004

Hi Michael,

>> Though I firmly believe, that if you do not need to change your  
>> system,
>> it is basically dead, and if you need to change it, you need tests.
> But if I don't (*change the base system*) but build on top of it I  
> don't need the base image tests.
> How often do you change the class builder on a giving work day?
I certainly also don't do it. But I love the fact that I could. By  
And it would increase the chances of the class builder to be improved.

To cite Alan again, from  
But the best way to approach the learning you are about to do is to  
consider Squeak as a metalanguage that can build languages. Besides  
learning how to make things with the existing features, also try to  
learn how the features themselves were invented and made. All the code  
is visible, and much of it has explanations of how it works.
Here, the system is the curriculum.
So the question is, if I want to be able by default(!) to change the  
system or  to "only" use it.
I get very much fun out of Squeak that I am able to change it. On many  

( Ok, you just answered this in another mail, so we agree here. Problem  
is, that I am afraid, that we,
the developers, only get the tests at relase-time of 4.0 or whatever.  
And then they are removed again,
because we want to develop on a "clean" image... :-/ But maybe I  
misunderstand this???? )

Certainly this is an idealistic view and I also understand constraints  
like the size of a plugin-image.
And I guess you want to be able to build a "test-free" plugin-image on  
top of the base-image.
And Etoys-Users really don't want to start with changing the class  

On the other hand, I find projects more and more useful to teach  
Smalltalk itself.
See a little example at:


And for teaching Smalltalk I want to have SUnit and tests and yes, even  
example usage of the class-builder.
Maybe we should come up with some kind of more transparent  
loading-by-demand mechanism.



More information about the Squeak-dev mailing list