Doug Way wrote:
[snip]
However, I understand that getting this Full Assembler package together is a lot of work for Diego. So if he wants to limit the amount of developer goodies to a modest number of things for now, that makes sense. I guess it depends a lot on which packages tend to cause conflicts by overwriting methods, etc...
[start emphasis]
that should be discouraged as much as possible and we should get any necessary changes into the base image instead.
[end empasis]
Right. I want to give support to this. I read it as Doug wanting to use the energy of the developers of developer-goodie-packages to help improve the quality of the base (image).
That is a great goal and it might just work, also because the developers of developer-goodie-packages are rather well-positioned to improve the quality of the base. After all, the knowledge they acquire about the base in order to be able to build their tools in the first place, helps them to be able to improve the base too.
It seems that historically, this has not always been how it goes. Is it accurate to think that frequently, a change to the base for the benefit of one package, breaks one or more other packages? I haven't been keeping logs about such events, but from following squeak-dev and my own experience of trying to load add-ons, it seems like this does indeed happen.
How to improve this situation? I see two approaches that might help: 1) self-testing packages 2) "hygienic packages"
Ad 1), self-testing packages: If packages are equipped with a command to run a self-test, which verifies whether they are working well, all such packages can be loaded together in a "dev-all-self-testing" image and any possible problems identified. So the message to the goodie-developers is: equip your work with a self-test button, and we can include it in "dev-all-self-testing" (which could be the base from which to build "dev-full"), and ensure it works up to the level of assurance that you yourself have built-in through the self-tests you included.
Ad 2), "hygienic packages": A "hygienic package" is a package of which we can know in advance, that it does not break any other package. This is something that would depend on a working namespace system. Because all the code is in its own namespace, then if no other code in our image uses the same namespace, we know that loading the hygienic package can't break anything in our image. Loading a "hygienic package" also can't break any other "hygienic package" we might want to load later (unless they use the same namespace, which is not difficult to avoid).
[I have studied Goran's namespace proposal, including the code, and it would seem it enables hygienic packages. But it does a few other things as well, and I would rather advocate, as a first step top take, the simplest namespace system that can work: which would be a namespace system that does just enough to enable "hygienic packages". This would use some form of Andreas' parser mod allowing Xxx::Yyy global names, which I think is not only clever, but in this case also a good idea :-).]
Self-testing packages can be done without having namespaces and would start to help avoiding functional conflicts going undetected, and reduce the workload of the people who integrate things to produce distribution images.
BTW, self-testing packages are not just a wild idea: I have written all my packages to be self-testing for quite a while, and it works excellently. QA is very effective and not much work. I use the self-testing ability to do TDD on those packages as well, but that is optional and there are many parts I have designed up front as well, and then completed/enhanced with TDD and secured with regression-tests. My packages include their own tests, but they also include their own testing and error-reporting engine. But this last aspect (having your own engine) is by no means required; an external testing/reporting tool like SUnit can be used as well.
Having no concrete plans to implement any of this myself specifically for Squeak, take-up of any of these ideas depends on others. So, does this make any sense to anyone here?
Cheers,
Peter