Of course, it's not the sort of argument that validly proves my point is
right and yours wrong.

I'm highlighting a trade off. We got lots of flexibility for the cost of
classes (which is not negligable - OO is harder than imperative
programming, for simple enough programs). We do actually want software
complex enough to justify it, so it's a pretty good deal. 

Coexistance of modules adds yet another such layer of ambiguity. Ok,
that's a cost that's not unthinkable, but also not negligable. What
exactly are we buying? how do we make the cost not hurt us too much?

I happen to think that right now in the Squeak community, it is very
rare for a person to want to load two versions of a package, among
things, because most of the time people are working with either their
own code, or something that came in the specific image they loaded. The
situation is very simple, not much potential for conflict.

As it becomes easier for people to publish, maintain and use projects
outside the image, and for packages to depend on one another, we might
get to the point where conflict happens more often. Eventually, the
tradeoff might look quite different.

IMO, open/closed source makes quite a difference to the trade off - with
open source, it might be easier to fix the conflict between the two
packages than to live with it. This is much harder with closed source
software - you can't fix what you can't see.

Daniel Vainsencher

Les Tyrrell <tyrrell at canis.uiuc.edu> wrote:
> I don't buy that as a valid argument- the same thing could have been said in
> response to the notion of having classes contain subroutines.  "If I am in the
> debugger looking at subroutine blah();  how can I know which blah() I'm
> looking at?".  I don't think the solution to that problem turned out to be all
> that bad, and I don't think it matters whether you are dealing with closed or
> open source.
> 
> - les