Hi andreas

Even with Java or languages with a static type system, nothing prevents
you that your system will break. There are a lot of research papers on 
that and none
provide a good solution. Between one version and another one the same 
interface
can hold but the behavior slightly changes and break everything 
(fragile base problem for example).

The minimal first step would be to be able to rely on well-known and 
identifiable versions of other components (package).

Stef

On Mercredi, nov 5, 2003, at 08:32 Europe/Zurich, Andreas Raab wrote:

> Hi Guys,
>
> Here's a weird and somewhat OT thought that was triggered by a 
> discussion I
> had today. One of the things I am noticing when looking at SqueakMap 
> (and my
> use of it) over the last year is that many of the packages that are
> available from SM tend to break in the face of later Squeak versions. 
> What
> happens? Effectively, these packages have been written under the 
> assumptions
> of a certain environment in which they exist (namely that of Squeak 
> X.Y) and
> if these assumptions are ever (even partially) invalidated they break.
>
> In the discussion I had today Alan (again) mentioned that one of the 
> things
> that could be done for making sure an object (or a package) can 
> survive in
> some environment is to model (at least some) of the assumptions about 
> the
> environment explicitly. We do this internally by, for example, using 
> unit
> tests for the package but typically we have no model whatsoever about 
> our
> environment. This is (at least I think so) an even larger problem for a
> dynamically typed environment than it is for a statically typed 
> environment.
> In the statically typed environment you can at least be assured that 
> the
> compiler will do certain checks on your types (and messages) so unless 
> the
> semantics of some message (or type) changes you should be safe (in 
> theory).
>
> What I'm curious about here is: Has anyone ever seen a (hopefully even
> usable ;) approach to model "environmental assumptions"? Are there any
> common rules/guidelines on which "environment tests" could be based?
> Anything else in this area?
>
> Cheers,
>   - Andreas
>
>
>