The future of SM...(compatible library packages)

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Aug 4 09:47:01 UTC 2004


Hi Trygve and all!

Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> There has been many suggestions about how a package can survive a change in 
> its class library. I believe the only workable solution is to let a package 
> include all required objects and ignore any new versions that may come along.

It is worth to note here that the compatibility level idea is not meant
to be the fundamental mechanism in the dependency model - it is instead
meant as guidance, especially when the combination of packages creates
conflicts in version (Package A1.0 needs B1.0 but C1.1 needs the newer
B1.1) and you might need to try using a newer release that hasn't been
tested yet.

So... the idea is to use the tested specific releases of required
packages - just like you say - if there is no conflict. But when
conflicts arise the idea is to be able to get guidance in trying new
combinations.

The idea of being able to have multiple versions B1.0 and B1.1 installed
*at the same time*, as you suggest - is an idea that both doesn't have
support in Squeak today and would also lead to... IMHO confusion and
possibly strange social effects.

With "social effects" I mean that it may very well lead to less reuse
and less pressure on us developers to play nice with each other and
build layered systems and/or respect each others development cycles. I
mean, getting a statically built executable installed in my Linux box is
simple - but the fact that it has "its own" of everything built in is
not always a good thing.

[SNIP of interesting examples]
> The surface area between a system of classes and their superclasses is 
> enormous, there is no way the library developer can foresee the effect of a 
> change on the many and unknown users of the library. My own experience is 

True, the developer can not foresee *the exact* effect on *all* users of
the library. But he should be able to assess the impact of the change.
IMHO a working solution in this area needs to be based on pragmatism and
social behaviour much more than theoretical mathematical exactness.

In this line of thought it is simply better if there is information
about the expected impact - even if it will be wrong in x% of the cases.

> also that it is practically impossible for an application developer to see 
> the effect of hundreds of changes in the library even if they are carefully 
> listed (as PPS used to do).

Definitely. But I still think it should be possible to classify the
level of compatibility, at least without being totally off. :)

> The solution I dream about for BabyUML is that it shall support many 
> versions of a class simultaneously. Library classes shall not be known by 
> name, but by object ID.

Similar to what Craig wants with his Squat work I presume. I still think
it is a simplification that doesn't hold.

> The loading of a package should automatically cause 
> the loading of the objects it requires if they are not in the image 
> already. Object IDs must be unique in time and space. I estimate 90 bits, 
> but local aliasing should be possible for efficiency. It seems sensible to 
> use a finer granularity than class objects, "Traits" looks very promising 
> in this context.
> 
> Finally, testing can only show the presence of bugs and not the absence of 
> bugs. Bug free software takes bug free design and bug free implementation. 
> The purpose of testing should only be to confirm that everything is OK. But 

I agree, testing shows that "the things being tested works". It doesn't
say anything about the things not being tested. :)

> our present programming paradigms do not yield readable programs. The goal 
> of the BabyUML project is to make it practicable to create simple solutions 
> to complex problems.
> 
> Cheers
> --Trygve

regards, Göran



More information about the Squeak-dev mailing list