Lex Spoon wrote:
> Andreas Raab <andreas.raab at gmx.de> writes:
>> Well, that's great as long as it is *your* foot. Unfortunately, when
>> modifying a base class that other modules use you are not shooting
>> your own foot - you are shooting the *other* guys foot (since your
>> module will work happily with those modifications but the other
>> modules won't) and that's not okay for a module system.
> 
> 
> This is one real issue, but other issues point in the opposite
> direction.  It's not a clearcut question.

It is a very clearcut question as far as I am concerned. What I am 
interested in, however, is not a components utopia (btw, your write-up 
was the most painful thing I've ever read from you because it is so full 
of baseless presumptions) but rather exploring the possibilities of 
loading non-interacting modules side-by-side and from there enable 
interactions between them. The way you are phrasing the problem you are 
basically giving up without even trying.

For example, a simple, yet perfectly valid answer to the problem is to 
load different versions of modules in different images, or, even more 
extreme, on different computers. Mind you, these modules can still be 
enabled to interact by using the network to communicate, however, for 
the purpose of our discussion, they *are* perfectly isolated against 
each other. And now tell me why this is "utopian" or why we shouldn't 
enable something like that from within Squeak to minimize communication 
overhead and space requirements where possible.

And once we start looking at it from that angle we see that -starting 
from perfect isolation- there are scopes at which we expect modules to 
be isolated (across machines) and scopes at which we expect them to 
interact (for example, inside applications). With that basic model, we 
can explore which interactions we can enable while still adhering to 
whatever strictness of a isolation we'd like to implement. None of which 
is utopian, or a halting problem or whatever; just deliberately chosen 
tradeoffs. (to come back to the original thread, Java took one stand on 
these issues and judging from the results they seem to work)

> Also, notice that Smalltalkers just love adding methods to base
> classes.  Have you ever tried writing Smalltalk code without the
> abilitity to add anything to Object? 

Yes, I have. And if not for the need of having a very fast type test 
(Object>>isFoo) I have rarely a need for them (and try to avoid them as 
much as possible). Yes, there are situations in which modifications to 
class Object can be useful, however, most of the time there is no need 
for them and in the long term you are typically better off without them 
than with them (partially because you write your code more defensively).

Besides, there are a few changes to the language that might dramatically 
help with solving these issues - I have recently started to think about 
traits in that way, e.g., to be able to "import" an API that immediately 
delegates to some other implementor (this particular thought was 
triggered by the realization of traits being the equivalent of an 
#include<> statement and one of useful the things that does is giving 
you access to a name space - in which case you can say "self do: arg" 
and the trait might map that automatically into "FooImpl for: rcvr: do: 
arg" or so - I'm not sure where this would lead to but the current uses 
of traits really resonate with me as solving the wrong problem at the 
wrong time in the wrong context ... and yet, I do think that there may 
be a pony somewhere) Unfortunately, you'd still need that very fast type 
test and possibly also the need to query for a default implementation.

In any case, I think that the "love to adding methods" is pretty much a 
red herring in this discussion. It is one of the possible tradeoffs you 
can make but it is certainly not the only one. And I'm sure we can find 
solutions for it if we put our mind to the problem (as a matter of fact, 
Dan made at least one concrete proposal towards that exact problem which 
wasn't exactly utopian either).

Cheers,
   - Andreas