<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Namespaces: Pink and Blue</title></head><body>
<div> <br>
As already mentioned by Peter Novak, we are re-implementing in Squeak
the namespaces we have implemented in VisualWorks in 1992 and since
then used within our technologies (ArtBASE, ArtGUIDE) and
applications. We will release the first version of our
Squeak-Namespaces by the end of this week.<br>
</div>
<div>Here I want to tell a few words about the concepts we are
following.<br>
</div>
<div>*****<br>
</div>
<div><b>The Nature of Naming vs. Smalltalk</b><br>
</div>
<div>In real life, names are used for symbolic identification of real
things which are known under this particular symbol in the particular
context. Such things known by name are _notions_. The naming itself is
a message to the receiver - he/she receives the message and
understands in the particular context the particular thing - notion -
under this name. Hence - a sentence (a kind of real-world expression)
start with a message send to the receiver in the particular context
!<br>
</div>
<div>In Smalltalk, expressions start with a variable or a literal.
Literals are "simple data" which are instantiated in
compile-time. Variables are place-holders for objects which receive
the subsequent message in run-time. The variables are assigned in
compile-time, i.e. they are _not_ message sends but assignments.
Hence, from this point of view, early binding is used for the
identification of the primary receiver of the first "normal"
message in an expression (this is true for all kinds of variables -
temporary, instance, class up to pool dictionaries and global
variables, although the last ones are accessed not directly, but
rather via a "remote" object - an association).<br>
<br>
</div>
<div><b>The Problem</b><br>
</div>
<div>The problem is that in the real life, other things may be ment
under the same name in a different context. Notions related to a
common context (e.g. to all golf players) are grouped into their
common vocabulary which they use when talking with each other (i.e. in
"their" context). Some of the words used by golf players may
have a completely another meaning within an another community. Let us
call such "vocabularies" to be _categories_ - a category
contains notions and is able to resolve the particular name and return
the relevant object.<br>
</div>
<div>I.e., a category is that what we call namespace. A category
(namespace) is completely different from a class - while the class is
used for modelling the kind of things (their common structure and
behavior), categories are used for modelling the symbolic
identification of localy or globaly known objects. Classes are notions
by default. A category can group completely different classes (from
different subtrees). Their subclasses can be located in another
categories.<br>
</div>
<div>In fact, in real life we have too few words in our languages to
describe the variety of the real world things and situations in an
unambiguous way. Hence, we have to use categories - namespaces and
contexts to be able to communicate what we mean to other people in the
"normal way" - by natural language. If a problem arrises
("does not understand"), a "callback" from the
receiver to the sender is started in order to get more information
about what had been actually ment by that particular name. Most often,
this information is provided by explicit naming the "vocabulary"
from which the used word had been taken.<br>
</div>
<div>Hence, the real world is polymorphic also in naming the
receivers, not only in their responses to the subsequent messages
(methods). This enables to achieve the description of the variety of
things and situation in real life with the limited vocabulary of
natural languages.<br>
</div>
<div>Also, in real worls namespaces are being specialized. If you have
a common namespace for al sciences, then it may be specialized by a
namespace for mathematic, then for algebra etc. etc. In each of the
sub-namespaces, all notions from the super-namespace are valid (unless
redefined) + new notions specific to this particular namespace are
added. In a neighbour namespace (with common parent), some names may
have another meaning.<br>
<br>
</div>
<div><b>Pink plane</b><br>
</div>
<div>In the pink plane of Squeak Namespaces, there is the intention
not to change the way how Smalltalk works but to offer the namespaces
which can help to model "categories" - real-world
vocabularies, in particular to achieve the polymorphism of global
variables and pool dictionaries. The basic approach is almost the same
as described in the paper from 1992:<br>
</div>
<div>- Namespace is a subclass of Dictionary; namespaces enable to
hold objects under different names; Smalltalk is the sole instance of
SystemDictionary which is subclass on Namespace (it's a special
namespace which also represents the system as a whole),<br>
</div>
<div>- a namespace can inherit from another namespace - the namespaces
build a directed acyclic graph (multiple inheritance); if you are
looking for a notion in a particular namespace, you "understand"
all the notions from all superodered namespaces; I prefer inheritance
to "importing namespaces" - with inheritance we can model
the _specialization_ of existing namespaces, where several different
specializations may co-exist beside each other and provide e.g.
alternate objects for the same naming; with multiple inheritance, you
can always join all namespaces you intend to use to be parents of your
"working" namespace - e.g. after having Smalltalk divided
into namespaces Kernel, Numeric, Collections, Compiler, ..., you can
create namespaces Development and RunTime - the RunTime namespace
simply would not include compiler, browser etc. while the other
would,<br>
</div>
<div>- Smalltalk is the default root of namespaces; another roots are
possible, but they must be accessible from Smalltalk or some of its
sub-namespaces; such separate roots do not inherit anything from
Smalltalk, e.g. you may build a completely different collections and
use them in your applications,<br>
</div>
<div>- global variable CurrentNameSpace is added in Smalltalk which is
always set to some of the namespaces; in this namespace expressions in
workspace are compiled; it may be used and changed by applictions,<br>
</div>
<div>- the path in the namespaces is identified by subsequent message
sends, e.g.<br>
<tt> MyApplication Interfaces MyClass new
....</tt><br>
or<br>
<tt> (Smalltalk Set = MyApplication
Collections Set) ifTrue: [.....</tt><br>
</div>
<div>- classes know their namespaces - variable 'motherNameSpace' is
added to Class; all methods are compiled in this namespace, incl.
inherited globals; when a class is moved between namespaces, it has to
be recompiled; classes may be subclassed in another namespaces,
subclass may mave the same name as its superclass (if in anoyther
namespace)<br>
<tt> CurrentNameSpace := MyApp.</tt><br>
<tt> Smalltalk Set subclass: #Set ...</tt><br>
<br>
</div>
<div><b>Blue plane</b><br>
</div>
<div>In the blue plane, static vs. dynamic identification of the
primary receiver in expressions is the major question (beside
namespace functionality of the pink plane) - the SELF-like messages.
Some thoughts in this direction:<br>
</div>
<div>- first token in an expression should be a message send to
thisContext which would find what it means;<br>
</div>
<div>- temporary variables are the "attributes" of the
context - they could be known (inherited) in all subcontexts; they are
accesed and modified only by message sends, e.g.<br>
<tt> name = 'Peter' ifTrue: [...</tt><br>
<tt> name: 'Peter' ..... (which means
"thisContext name:...")</tt><br>
</div>
<div>- instance vars are "attributes" of the object in the
same way,<br>
</div>
<div>- class vars should be similar "attributes" of the
class while pool dictionaries would be substituted by namespaces,<br>
</div>
<div>- globals are entries in namespaces,<br>
</div>
<div>- literals: even literals could be understood as message send to
thisContext and interpreted in the right way, e.g.<br>
<tt> 95 factorial</tt><br>
means an integer to be send a message #factorial for everybody
but Bill - he would send it rather to windoze<br>
</div>
<div>All this are really just thoughts because it would impact the
readability of the code for "all smalltalkers" too much -
not ot talk about performance, ... Hence, so far from the blue plane
we are implementing the identification of global variables only (as
message send to self, not to thisContext).<br>
</div>
<div>Blue plane (even with globals only) leads to a full polymorphism
and hence higher reuse: even the same method may run completely
different in applications running in different namespaces (since
globals in ti wil be looked up in run time). Hence you can easily
plug-in new libraries, test your applications with each of them,
choose the best one etc.<br>
<br>
</div>
<div>Augustin Mrazik</div>
<div><br>
Content-Type: text/x-vcard; charset=us-ascii;<br>
name="amr.vcf"<br>
Content-Transfer-Encoding: 7bit<br>
Content-Description: Card for Augustin Mrazik<br>
Content-Disposition: attachment;<br>
filename="amr.vcf"<br>
<br>
Attachment converted: Anon:amr.vcf (TEXT/R*ch) (0001214C)</div>
</body>
</html>