Hi Trygve and all!
Trygve Reenskaug trygver@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