On Wednesday 21 August 2002 03:05 pm, konrad.hinsen at laposte.net wrote:
> I have just started playing around with Squeak, and I am duly
> impressed... with just about everything except the state of
> documentation.

Yes, this has been commented on. I think there are positive steps in 
the direction of improving this.

Have you seen the Squeak Swiki (http://minnow.cc.gatech.edu/squeak) 
yet? It has lots of information, though the organization and updating 
could stand improvement.

> For example, before I start any serious project, I would like to be
> sure that I don't loose my work due to stupid mistakes, careless
> import of code, a system update, or whatver else might happen. I
> have seen plenty of references to file ins/outs, changesets,
> projects, etc., but I don't really know what I should use in which
> circumstances or for what purpose.

Change sets maintain related code changes under a name.
You can file these out and back in, if you want to save or distribute 
a particular body of work. Most Squeak enhancements and fixes are 
distributed this way today.

As you change things in your system, the changes file records them. 
Even if you trash your image, you can browse and file in individual 
changes from a changes file.

Projects let you save a World in binary format with all its objects. 
You can also choose to save the current Change Set with the project.

Modules will become the preferred packaging format sometime in the 
next couple of years. These know about dependencies and may be able 
to be unloaded from the image.

> A related problem is the evolution of the whole system. There seem
> to be neither "undocumented" nor "officially documented" parts in
> Squeak. So if I want to make sure that my code will still be useful
> next year in Squeak 42.7, what can I safely rely on?

Parts of the system tend to change faster than others.

The base system (interpreter, collections, processes, etc.) doesn't 
change as fast, though there have been some changes in the last few 
years and will continue to be some. However, changes that affect the 
Squeak Virtual Machine are usually done with backward-compatibility 
in mind. Recent changes to Squeak's innards include exceptions, 
changes to the event handling, (someday) new block contexts/closures, 
and maybe a few others.

The Modules system added in 3.3 will be a big change, but older change 
sets should still file in OK.

MVC hasn't changed much at all, though there have been new tools 
added.

Morphic itself has changed some in the last few years. But it's not 
too hard to update older Morphic code to work in current images. I 
expect that its rate of change will be slowing some in the future.

Other pieces -- applications, tools, games, etc.-- will come and go.

The Scripting/eToy system is still undergoing change, as are other 
pieces of Squeak. But these changes shouldn't be too disruptive.

I wouldn't be surprised to find some problems filing in older projects 
in the future. But there are provisions in the project loading to 
convert to newer versions; if done carefully, this can let older 
images or projects work with new code.

There will be other changes, certainly; like any other evolving 
software system, you may have to re-visit your code to prevent 
bit-rot from setting in as versions change. But it hasn't been too 
bad recently (there is still Squeak 2.6 code that works fine in the 
newer images).

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE