Andreas Raab <andreas.raab at gmx.de> writes:
> Well, that's great as long as it is *your* foot. Unfortunately, when
> modifying a base class that other modules use you are not shooting
> your own foot - you are shooting the *other* guys foot (since your
> module will work happily with those modifications but the other
> modules won't) and that's not okay for a module system.


This is one real issue, but other issues point in the opposite
direction.  It's not a clearcut question.


Note that the purist stance for modules does not work.  That way lies
the mythical components utopia [1], where arbitrary combinations of
modules Just Work.  In practice you need some way of dealing with
inter-module problems.  Whatever that mechanism is -- and for many
communities it can be as simple as maintaining a list of all the
modules in the "world" -- that mechanism will take pressure off of the
module system's built-in checks.

Also, notice that Smalltalkers just love adding methods to base
classes.  Have you ever tried writing Smalltalk code without the
abilitity to add anything to Object?  Java programmers want it, too!
I keep reading articles by guys trying to open up Java classes for
modification by outside modules.  I keep wondering whether they'd be
better off just doing the simple Smalltalk thing.

For Smalltalk, my inclination is to at least allow *additions* to
classes in other modules.  It's very useful, and it does not appear to
be a big enough source of bugs that it should be outlawed.
Practically every Smalltalk code-loding system allows this....


Lex


[1] http://www.lexspoon.org/blog/components-utopia.html