[Cuis-dev] The other way to do namespaces

[ken.dickey at whidbey.com]

Luciano,

Thank you much for your thoughts and work on this.

I also have much to do in my life outside Smalltalk.  I wish you all the 
best!

I have seen and used Namespace based system organization in a number of 
runtime systems.

I think it is good for you to do the details on this to see how it might 
play with the tools in practice.  This includes hiding prefixes and 
showing what Namespaces (perhaps multiple?) that code belongs to. Making 
and exploring Namespaces also requires tool work.

My choice of Environments (dictionaries of Classes) allows me to avoid 
changes to parsing and I am finding it interesting to explore how the UI 
tools are implemented.  Also, I am interested in being able to have 
multiple versions of a single Feature/Package which I can easily do with 
Environments.  I find the Namespace solutions for this a bit more 
complex and this also adds to UI tool work.

Another of my goals is to export fewer bindings to Smalltalk.  Having, 
e.g. several card games loaded where each defines a CardMorph but 
Smalltalk has _no_ binding for CardMorph seems a simpler solution to me 
than a SysytemDictionary with bindings for FreeCell.CardMorph, 
CardsPoker.CardMorph, Bridge.CardMorph, ...

Again, there are many ways to approach this.  I am travelling down a 
path that seems simplest to me.

Good on ya,
-KenD
=================

On 2020-06-30 02:24, Luciano Notarfrancesco via Cuis-dev wrote:

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