Roel Wuyts <Roel.Wuyts at ulb.ac.be> writes:
> Andreas, I prefer refactoring, but refactoring assumes a closed world
> approach where you control all the pieces of the puzzle.
> 
> It simply is not always possible to refactor (because you do not have
> the source, because you do not want to create a fork, because you
> have other programs that absolutely rely on the old behaviour, etc.).

Exactly.  It also assumes that even if you have the code, you can
convince the other guy to make the change.  This is a significant
burden.  You are better off if you can propose your module and then
let people try it.  If it is popular, then the other guy will know
your code is not loopy and so will be more amenable to cooperating on
a refactoring.


Shout replaces the system text editor, which in my mind is an invasive
change that is just the sort of thing hard-shelled modules would be
likely to disallow.  I can assure you, the behavior of a lot of things
changes when you have Shout loaded.

There are plenty of other examples, though.  Extreme examples would be
Zurgle and Genie.  These old packages changed various classes in
Morphic when they were loaded.  Interestingly, one became standard,
and the other faded and stopped being maintained.  Open modules worked
well for these cases; they let the proponents post their code for
people to play with, without immediately needing to get the standard
Morphic classes refactored to suit them.  And anyway, they were both
probably lobbying for standard inclusion, anyway, so refactoring
hooks for them would be superfluous overengineering.


Those are extreme examples.  There are a lot of intermediate examples,
too, where you want to add a few thing to Object to make everything go
smoothly.  Look at the code for GOODS or SIXX sometime.  GOODS adds
"isGoodsImmutable", which I guess you would say should be supported
through a type-check mechanism.  Fair enough.  How about SIXX's addition
of Object>>sixxInitialize ?  This method is supposed to be called
when an object has finished initializing.  It cries out to be placed
in class Object, so that you can just send this message to the object
and let it take care of it.  In this case, I don't even think the system
code should be refactored -- this is a great Smalltalk design the way
it is.


In practice, it has proven very valuable that Smalltalk modules are
allowed to modify the system classes.  This is a dangerous thing to
do, of course, but I would really hate to handicap the above fine
packages just because of the *potential* for danger.  Instead, we
should admit that inter-module conflicts exist, and deal with
them head-on, as they happen....



> In that case extending the existing software from within your own
> package helps, but should be used sparingly for all the reasons you
> mention.
> 
> Note that a decent module system should support both.


Fully agreed on both.



Lex