3.7 Full: Developers or Media users?
Peter van Rooijen
peter at vanrooijen.com
Fri May 21 11:07:04 UTC 2004
Doug Way wrote:
> 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...
> that should be discouraged as much as possible and we should get
> any necessary changes into the base image instead.
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
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
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?
More information about the Squeak-dev