"Environment tests"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Nov 5 13:29:00 UTC 2003


Ok, people - now I can't hold my tongue anymore. :-)

Since the inception of SM I have been thinking/working on these problems
but I am approaching it from the side that Alejandro talks about. All
you others talk about cool advanced techniques, no offense of course -
interesting stuff - but I do think there are simpler and quite effective
ways. ;-) 

Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> A thought experiment:
>          A package is a bounded object space.
>          Many versions of a package can coexist in an image.
>          Any version can replace any other
>                  if they are identical.
>          A version can replace different one,
>                  but only under under certain conditions.
>          The base Squeak release is a package.
>          A package that uses/builds on another package identifies
>                  this package and its version
>          My NewStuff package declares that
>                  it merges any number of (package/version).
>          When somebody runs MyStuffmuch later, MyStuff will still use
>                  the proper package/versions.
> 
>          If MyStuff is popular, I might later update it to use a newer 
> package/version to reduce total system complexity.
> 
> I know - this may be just a dream. May be somebody has done the research 
> already.

Trygve outlines ideas at least "touching" on what I am working towards
with SM. One of the big inspiring sources is (this has been stated over
and over) of course Debian.

SM is very much inspired by the apt-get system in Debian.

The simple idea that I am working towards in SM2 and beyond is that each
release should be mandatorily classified in terms of "backwards
compatibility". Exactly which levels there should be is of course up for
discussion, here are enough to show the idea:

1. No compiled code has changed. (class comments, method comments,
categories) Machine verifiable.

2. Compiled code has changed but author believes external behavior is
identical. In-method efactorings for example, or performance tunings.

3. Stuff has been added (classes, methods) but none of the existing
stuff has changed more than level 2 above.

4. External behavior has changed but not for a client to the package. No
added or removed methods in any classes, but methods have changed their
behavior. Many bugfixes could be like this. No behavior changed in the
methods that represent the external API of the package.

5. API behavior has changed, meaning that methods representing the
external API has changed. But the API still holds, no changed selectors
nor changed meanings of methods.

6. API has been changed but the author believes that old clients "should
still work".

7. API has been changed and the author believes most old client will not
work, but they could.

8. API has changed and the author can promise that the old clients will
not work.


Ok, I have written similar levels a few times - and they always come out
a tad different. :-) But you get the point. Now, if we combine the above
classification with proper releases AND dependency information (this
release needs this and that release) then we get a lot of interesting
situations. The user will be able to "guess" and try new releases and
have expectations on the result. And new valid configurations can be
discovered etc.

Now, I am not going into how the dependencies IMHO should be structured,
I have written about that too many times already. :-)

regards, Göran



More information about the Squeak-dev mailing list