[Cuis-dev] The other way to do namespaces

[Luciano Notarfrancesco]

Hi Ken and all,
The last couple of weeks I've been having some personal problems, and this
is occupying all my mind, I'm having a hard time focusing on anything else.
So I wasn't able to continue working on namespaces, but I have this from a
couple of weeks ago and I'd like to share it with you.

This follows Goran's work, and it is an alternative to the idea of
implementing namespaces as concrete dictionaries. The idea is to include
the namespace of a class (or other variable in the Smalltalk dictionary) as
part of the class name (the key in the corresponding Association in the
Smalltalk dictionary). For example, the class Elephant in namespace Animals
would be named #'Animals.Elephant'. And the namespace Animals is a global
in the Smalltalk dictionary, an instance of Namespace, not a concrete
dictionary but a virtual dictionary. When you do something like 'Animals
at: #Elephant' the namespace Animals actually returns 'Smalltalk at:
#'Animals.Elephant'. And the bindings lookup when compiling code is
slightly modified so that methods of a class Lion in the Animals namespace
can refer to the class Animals.Elephant directly as Elephant.

One advantage of this approach is that it doesn't require many changes to
the base system. The biggest change was in Scanner in order to allow the
use of periods in class names, and Shout requires some fixes related to
this too. It might be nice also to change the Browser to show short class
names, or perhaps make an alternative Browser for that, not sure. In
debuggers and inspectors I find it useful to see the fully qualified class
name like Animals.Elephant. Another change that might be necessary in the
base system is in RenameClass and RenameGlobal refactorings, because it
might be wise to avoid moving classes and globals from a namespace to
another one, at least through these refactorings.

Sending the message #isolate to a CodePackage moves all classes of the
package to a namespace named as the package. For example, I tested this
with my Domains package doing this:
  (CodePackage installedPackages at: 'Domains') isolate.
This moves all classes in the package to a Domains namespace (for example
the class Graph is now named Domains.Graph).

Let me know what you think of this approach. Ken, this could be a way to
provide the same functionality as PackageEnvironments but with less changes
to the base system and less complexity. I don't want to step on your toes,
tho, and I'm not opposed to your approach with Environment... I'm just
providing extra information and code that might be useful for implementing
these things.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200630/cbc5d7f4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: System-Namespaces.pck.st
Type: application/octet-stream
Size: 30675 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200630/cbc5d7f4/attachment-0001.obj>