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