Martin Wirblat wrote:
> Keeping a modified version of the original package. What does that mean?

It means trading lazyness for robustness ;-)

Don't get me wrong, overrides are very convenient (too convenient 
perhaps) but I don't think most people acknowledge how problematic they 
are when you mix packages. The point here is that if you load a set of 
packages (apps or not) overrides *always* change the semantics of the 
package and therefore affect other users of the package. This is 
different to extensions which are only evil if, say, they're 
specifically used to change the semantics (say, by implementing an 
extension liks "Text>>isMorph ^true"). Fortunately, most extensions 
aren't used in that way.

Or consider this: Why can't I just load all of the packages on SM for 
any given Squeak version and have them work? Many of these will not work 
"together" and what does that mean? It means that there are semantic 
conflicts in the methods and those are expressed by overrides and other 
evil extensions. If not for those modifications, there is no reason why 
I couldn't have everything in my image running at once.

Personally, I have started to make it a rule to look at the extensions 
of a package before I load it. If it's empty, no problem, it's going to 
work just fine. Lots of extensions? Uh, oh. I typically run Tweak and 
Croquet images these days, and many a time I won't even bother to load 
the packages then.

> For publishing e.g. on SM you then would have to publish the modified 
> version of the original package, too. It is probably big and has nothing 
> to do with your application. As soon as the original changes, the 
> modified version had to be synchronized. All that because of one changed 
> method?

Exactly! So you'd have to think hard to minimize the interaction with 
the existing package and usually do something like convince the 
maintainer of that package to add/change whatever you need to get your 
job done. This is less convenient in the short term, but much more 
robust in the long term (also, don't forget that there are many things 
that can be done by subclassing - a technique that I certainly don't 
approve of in general either but it has its uses and it is definitely 
preferrable to hacking another package).

Or are you honestly happy with breaking a package you extend for some 
other application? :-) Even if you think it's a "fix", has that other 
application been tested with it? If not, how can you possibly tell?

> For publishing packages it should be of course tried by all 
> means to not override anything, but if this is not possible some more 
> elegant method seems to be needed.

I think about this in terms of robustness. The current solution may be 
convenient (not exactly elegant by my measures) but it is not robust.

> For private use this may not look much different. For instance, I am 
> regularly "fixing some inflexibilities of the official image" before I 
> use it, by overriding some things of the UI and perhaps other things. Is 
> that better done by creating some big modified versions of original 
> packages just because of a few changed methods? When the next image - or 
> worse the next interim update - comes out, I would have to sort out my 
> few changes from the possibly many official changes applied to the 
> package in the meantime.

Private images aren't relevant for this discussion - do whatever you 
like in them (I wouldn't even think of argueing what you should and 
shouldn't do with your own environment). It gets only interesting when 
you share your stuff with others because these others will be affected 
by your modifications.

> As long as you are developing a master image, it is the right way to 
> create modified versions of original packages. They immediately become 
> the new originals;) This kind of work is wonderfully supported by 
> Monticello with its many merging facilities. Nonetheless, if you want to 
> develop a second master *partly* synchronized with another master line, 
> there will be much work waiting for you, accumulating over time...

True. And I do this all the time with Squeak, Tweak and Croquet. But 
overrides are not the solution. They create more problems than they 
solve and there are better alternatives. Such as, for example, to define 
interfaces for the parts that you are interested in. I have done this, 
for example, first with ToolBuilder and now with the tools itself. It 
turns out that this is a much easier to understand, much more robust way 
of dealing with the subsystems since you have a (relatively small) 
well-defined interface to deal with and I don't have to worry and play 
catch-up with all the various developments.

> For all other purposes that want to derive from a master but want to 
> develop with the master (and that is the standard case), some sort of 
> "delta functionality" is needed. This delta should be as smoothly as 
> possible addable to the next version of the master, because this work 
> has to be done manifold (by the millions of the future, that are going 
> to use Squeak:)

I think that's very arguable. You are right of course, that for a user 
this should be smoothly to install, but for a developer, should the 
system really allow you to mess up an (end-)users installation just 
because you are lazy? Remember, the poor end-user has probably no idea 
why installing one app broke another one...

Cheers,
   - Andreas