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


On 11 Mar 2007, at 11 March/18:56, Andreas Raab wrote:

> Lex Spoon wrote:
>> Yes, that is fair generalization.  I would like the default module
>> format to allow unanticipated reuse.  Just look at the packages
>> Squeakers post for each other, and you will see all kinds of things
>> that modify the system.  How could you write something like Shout  
>> if a
>> module cannot change the system text editor?
>
> Err, by refactoring it in a way so that you can? We have already  
> various abstractions (AppRegistry) and there is nothing wrong to  
> have one that allows for syntax highlighting - with a common  
> protocol that allows other clients to hook into it, instead of  
> hacking the system text editor directly. Coincidentally, this is  
> *precisely* what I referred to earlier wrt. explicit vs. implicit  
> interactions. As it stands, loading an alternative syntax  
> highlighter will (almost necessarily) clash with shout; with that  
> interface both modules could use the same ground rules, could be  
> loaded side by side and could be activated depending on the context  
> you need them in.
>
> Cheers,
>   - Andreas
>