I want to try and extrapolate from the discussion and make another  
suggestion ;-)

I have the impression that the thread seems to revolve partly about  
two hidden and different assumptions (bear with me for the moment):
- Andreas seems to be defending an 'anticipated reuse' model, where a  
module is a well-encapsulated black-box entity. Indeed, running in a  
different image ( 'classloader' :-) ) quite strongly enforces this  
encapsulation.
. Lex seems to be more in favour of an 'unanticipated reuse' model  
where anybody can add elements.

Both models are at the extreme ends of the spectrum (more robust vs.  
more brittle, more closed vs. more extensible).

In the same vein however that object-oriented programming opened up  
black-box modules known from procedural languages (by differentiating  
two clients: the inheritor that has white-box access and the client,  
that can only call methods), I would propose to open-up the classical  
fully encapsulated solution you get with a closed module system by  
thinking about what inheritance between modules would look like.



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