Andreas Raab <andreas.raab at gmx.de> writes:
> 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 am thinking of the fact that some versions of Shout have messed up
Celeste's message pane.  It was no big deal, but the modules did
interfere with each other.

But it sounds like Shout isn't a great example.  How about
NewCompiler?  As of version 117, it still had a lot of additions to
the system.  I would argue this is fine; if someone is proposing a new
compiler, they do not need to coordinate a bunch of hooks in the
system for replacing all the odds and ends that this would entail.  At
least for getting started, we may as well have people post the version
that includes overrides and go from there.

Sealed modules, for all of their benefits, would seemingly disallow
this approach.



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

I meant nothing cheap here.  These are outrageously cool modules which
made system changes when loaded.  If you think open modules are evil,
how would you deal with add-ons like these two?



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


And how do you define isSixxObject?  I think you are stuck shifting
the potential conflict from place to place.  You can say that
SixxObject is a type, and you'll use isKindOf:, but now the type is in
a global namespace.  So how do you keep the global type name from
confliting between modules?  Maybe you say global names are
hierarchical, but even that is not an absolute guarantee that the
names will stay unique.  Use DNS names?  That only works until two
college students use their department's DNS name.

The only way I see to take the extreme stance is to abandon all global
namespaces and have explicit imports and exports and explicit link
scripts that tie a group of modules together.  Putting these link
scripts together appears to be rather a lot of work, though maybe a
system can be designed that both does it and is not too too onerous.

So, short of some radical change like this, it seems best to allow
modules to change things in other modules, especially relatively safe
changes like adding a method to another class.  I do not mean it has
to be easy or encouraged, but it should not be too onerous for people
who really want to do it.  It allows a lot more packages to be
proposed and tried.


Lex