The Form of the Squeak Release [LONGISH]

Stefan Matthias Aust sma at netsurf.de
Sat Jul 17 09:10:56 UTC 1999


At 11:17 16.07.99 +0930, Peter Smet wrote:

>I wrote:
>>A large monolithic image has IMHO another drawback which wasn't mentioned
>>yet. Because it's so comfortable, people don't thing about what
>>dependencies the subscribe to when adding code and you'll get a mess of
>>inter-dependent code which can't really separated.

>This is where that issue of factoring vs dependency raises it's head again.
>I once mentioned to the list that well-factored code seems to create more
>dependencies. If you want to make your new module as independent from the
>rest of the image as possible, you must 'roll' all your own methods.
>However, according to the rules of good factoring, you should use a
>pre-existing method in the image if it has the same functionality.

I don't agree - or at least I only agree partly.  It's all about
compromises here.  Feel free to refactor your code, but don't change other
modules.  If you like, use them, but make this dependency explicit.
(Please note, extending a class is already a change.)

Let's say we can distinguish between system modules and user modules and
also agree upon that let's say PWS is a user module.  Now if you want to
use a method (or class) from a system module, I see no problem.  If you
want to use some code from a user module, you might want to rethink this -
because it might sound strange if the programmer has to load the PWS module
only because it contains some nice collection methods you want to use in
our otherwise totally unrelated-to-web-servers application.  

What's now?  Implement these methods on your own. Or talk to the other
module's author and perhaps to other people to setup a new user module
(like a shared library) which contains the code you both want to use.
Perhaps this will eventually become a system module.  

>This sets
>up dependencies and tangling. The two forces seem to work in opposite
>directions, which is a pity, because both well-factored and independent code
>are desirable features...

No, it only reduces the boundaries from the image to the single module.
IMHO, once you get used to the idea that not the whole image belongs to you
but is a collection of other people's modules things became much easier
again and you can create well-factored code.

>Kent Beck wrote an interesting article (I read it in his new book, but I
>think it was culled from the Smalltalk report) about meta-programming.

I'm not sure whether this is really an universal solution but for meta
programming I like this very much as this makes things explicit again.  The
code isn't spread all over the class library but nicely collected in one
class.  (Actually this resembles the mirror objects of SELF which also
encapsulate reflective programming features.)


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.





More information about the Squeak-dev mailing list