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@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
squeak-dev@lists.squeakfoundation.org