jp1660 at att.net>Yes, yes, yes, each category should correspond to a
namespace.

 

I strongly disagree.

 

Class categories were never intended to serve as namespaces.  They were and
are intended to be completely analogous to method categories.  The purpose
of both is to organize the code by logical concept or functional domain,
with the double aim of a) making the code more understandable, and b) making
it easier to locate existing code that deals with a particular functional
area.

 

Whether class categories are worth preserving has nothing whatsoever to do
with either namespaces or "packages" (to use VW terminology.)  I understand
that many feel that having class categories, namespaces and "packages," all
as orthogonally separate entities, creates too much complexity.  Even if so,
repurposing class categories as namespaces would introduce a confusion of
roles, and the diachronic cognitive dissonance it would create would result
in even greater conceptual complexity, not less.

 

In contrast, a "package" (or "module," to use the term which both I and
Craig Latta prefer,) is intended to serve an entirely different purpose: to
encapsulate all the code (namespace definitions, variable definitions,
constant declarations, variable initializations, class definitions and
method definitions) required to implement/provide a separately-deployable
service, function, component or application. The key concept is "separately
deployable."  To provide the property of being "separately deployable," a
module must be able to completely install and initialize the service(s),
function(s), component(s) or application(s) that it encapsulates. And the
installation must be fully reversible.   

 

Ideally, modules should also provide for dynamic binding (and not require
static linking.)  In other words, a user should not have to load a module
into an image "by hand" in order to use it.  The module should be
dynamically located and loaded into the image when referenced.  It would be
bad enough for a language such as C to require that all "modules" be
"statically liniked." For the quintessential dynamic languge Smalltalk to do
so would be criminal.  Such dynamically-linked Samltallk modules would be
completely analogous to  a UNIX ".so" or Windows ".dll" file--and would
introduce all the same issues, all of which would be susceptible to the same
universe of possible solutions.  I suggest looking at way that
NextStep/MacOSX handle these issues.

 

"Separate deployability" also requires separate namespaces, since the idea
that every person or organization that publishes a module will be able to
coordinate the usage of names in a truly global namespace is simply not
workable.  This point should not even require any further debate.

 

And as I already sarcastically pointed out in an earlier post, all Smalltalk
implementations already have namespaces.  Generally, there is a namespace
for image-wide global variables, a namespace for the class variables of each
class, and any number of namespaces that can be shared among some set of
classes.  It is also usually possible to programmatically force the compiler
to use some namespace other than "Smalltalk" as the "global" namespace in
the lexical scope of a particular class.  With a few modifications to the
browsers and the class builder, Squeak can be made to support "private"
classes that live as class variables or pool variables, instead of as
globals in the SystemDictionary.  The point here is that the real issue is
not the introduction of some new "namespace" construct (one already exists,)
but rather how the existing namespace and class category constructs should
integrate/collaborate with the new "package" or "module" construct, and how
all these constructs should best be molded into an integrated whole.  

 

Conceptually, namespaces and modules/packages are orthogonal.  Whether they
should be implemented as fully orthogonal (as VW has chosen to do,) or
symbiotically bound together (as in a Java "package,") appears to be the
core of the issue under debate.  My opinion: Both the completely orthogonal
approach (as in VW) and the completely bound approach (as in Java) are
suboptimal.  Specifically, I think each module should be bound to a default
namespace, but that it should be possible to also declare globals (such as
classes) in namespaces other than the one bound to the module in which the
class is declared (e.g., in some class pool or shared pool.)  This approach
would mean that, by default, a Smalltalk module ("package") would work just
like a Java package--with which most programmers should be familiar.

 

However, for backwards compatibility, code that does specify any particular
module should be treated as being in an undeclared default module, so that
legacy code would work unchanged.

 

--Alan