[squeak-dev] Re: http://source.squeak.org/trunk is now at 3.10.2

Keith Hodges keith_hodges at yahoo.co.uk
Sat Jul 4 12:30:27 UTC 2009


I will start again...

My point is that any worthwhile refactoring project will probably
transcend the majority of packages, both in the kernel and without.

Example 1. Replacing FileDirectory - will effect a high percentage of
packages in the kernel and virtually every package in SqueakMap will
need to be ported.

Example 2. Namespaces - will effect a proportion of kernel packages and
MC tools, compiler etc.

Example 3. Replacing _ with := is not a project that is rescricted to
one repository.

Eaxmple 4. Logging

If you have a headless image, you might want to use a logging device
instead of Transcript. So every place in the kernel where people have
put Transcript show: in order to fulfil the role of "logging" would need
to be replaced with a call to the logging dispatch framework. i.e.

"Transcript show: someValue"   becomes something like "self log info
kernel someValue: someValue."

==

So here we have 4 projects that could be undertaken to improve squeak.
What do they have in common...

1. All of these projects could be applied to any existing squeak image,
cobalt, croquet, gjallar, pharo, 3.7 - 3.10 etc. So the potential target
audience is not just 3.11 users (who only represent a minority of the
squeak community).

1. None of them would be doable using the package maintenance model that
you are proposing. It is not true to say that one team can work without
bumping into another team as you propose.

2. You wouldnt be able to undertake any of the above projects
concurrently within a single repository, without people falling over
each other, and or the projects becoming inextricably linked.

3. The knowledge capture as to how to perform each project gets confused
with the activities of the other projects. Therefore this knowledge is
not useful to anyone other than the developers of that one image. If
Cobalt wants to use Logging too (and they already are doing so) they
would have to repeat all the work from scratch they would not be able to
reuse any of the knowledge gained from doing it in 3.10. Why? because
the the process of performing the refactoring was done against a moving
target, and it is not possible to say... You applied this process to
image 3.10 and I want to apply it to my image which is derived from 3.8,
if I analyse the differences between 3.8 and 3.10, I should be able to
take your delta  (DS/CS) and apply it to my image.

Keith



More information about the Squeak-dev mailing list