> Andrew C Greenberg made a very good point about the necessity of
> modularization for the success of an open source project. I second that.
> He also recognized that for modularity encapsulation features are required.

Actually, I noted that they are helpful.  I doubt they are "required" 
in the sense Stefan puts it.  Indeed, privacy encapsulation features 
are not part of Python, and the brief dalliance with it, I 
understand, may not survive into the next version.  Python is of 
course one of the most successful of open source projects, and the 
modularity of Apache is accomplished via shared libraries, which 
Squeak now supports.

*snip*

> Using a changes browser to check whether module A and module B will work
> together with my module C (an explosion of combinations btw) and fixing the
> problems manually cannot be the solution.  We need a mechanism which
> prevents the problems before they even arise.

This is a new sense of the word "need."  Time will tell.  And, as a 
nice by-product of Squeak, it being what it is, namespaces can be 
engrafted almost anytime.  As I recently read the VisualWorks white 
paper, it occurred to me that this sort of thing could be readily 
accomplished in time.

> Python, btw has a powerful module concept.  IIRC it has also a convention
> by documenting public interface methods and private implementation methods.

As noted above, Python's "convention" is not enforced by the 
language.  Guido opted against privacy to keep the language reflexive 
and open to tools, and the new privacy features are not being widely 
used anyway.  [In Python, identifiers beginning with "_" are 
scrambled by the compiler when compiling the module so that calls to, 
say "Fuzzy.__foo(object, parm)" from outside will be flagged as 
undefined.  On the other hand, an outsider can trivially access the 
method or variable directly simply by using the alternative 
(scrambled) identifier instead without a whimper from the system.]

Squeak also has such a convention.  Put private modules in a protocol 
category entitled "private."  If you really desperately need to have 
the compiler remind you of impinging upon private modules -- go ahead 
and have the compiler do that for you.

Anyway, namespaces might be useful, but they aren't a priority yet. 
Seminal squeak system resources are still being built, and much of 
the kernel still needs to be documented and polished.  (This is still 
a baby project -- isn't it amazing how far its come in just a few 
years? (piggybacking, of course, upon a decade of PARC's fundamental 
research!))

Unlike Python, however, Squeak is a Smalltalk, and modifying the 
language isn't something one does by fiat.  Deciding how to adapt to 
stated needs requires careful balancing of the demand, the resources 
available and the other stated needs of users.  In short, if you need 
it, build your namespaces facility.  [I would agree that a 
well-designed and upward-compatible solution would be desirable and 
might enhance further development.  I don't agree it is necessary in 
the sense Stefan is using the term -- Squeak can and will survive 
well without it.  Squeak is not Python, it is not Java and it is most 
certainly not Visual Basic.  There are upsides and downsides to all 
of those things.]

What it is, is the only serious programming system around anywhere 
that actually lives the dream of "write once, run everywhere." 
Something years of effort and hype have not been able to produce from 
Java.  You can, and I and others have, build serious applications in 
Squeak, in some cases in record time.  The term toy, whether Stefan 
intended it to be negative or not, simply isn't accurate or 
appropriate.