Lex Spoon wrote:
> 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. 

Not at all. Shout uses an API (AppRegistry) that is specifically 
provided for clients so they can pick up an alternative text editor if 
they choose to. No module system in the world would disallow interaction 
that is based on an explicitly provided API. Besides why do you call the 
change "invasive"? It does not touch any code in the system text editor, 
all it does is using an API that was explicitly provided for that 
purpose. Why is that "invasive"?

> I can assure you, the behavior of a lot of things
> changes when you have Shout loaded.

True. But since Shout uses an API a client can decide whether it wants 
to use any generic morphic text editor or whether it wants to use a 
specific one. That is different to your "solve conflicts with overides" 
approach which would give the client *no chance* to decide what to do. 
With Shout as it is (using the AppRegistry) I can easily switch the 
user's default choice of text editor to something else if that were 
necessary for my app to work properly. With a version that would hack 
text editor directly I would have *no such choice* making it somewhere 
between hard and impossible to actually get things working.

> 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.

Oh, that's cheap. It's not even worth responding.

> 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.

Not having looked at SIXX, it is of course hard to answer the question 
concretely. However, it isn't exactly the first time this problem has 
come up and with a type-test this simply becomes:

SIXX>>sendInitializeTo: anObject
	anObject isSixxObject ifTrue:[anObject sixxInitialize].


Nothing in this cries to be implemented in Object, except perhaps from 
the type test (which I have repeatedly admitted).

> 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....

Well, go for it. We'll be heading another way.

Cheers,
   - Andreas