[Cuis-dev] Namespace Code Sketch

[ken.dickey at whidbey.com]

On 2020-06-10 08:19, Luciano Notarfrancesco via Cuis-dev wrote:

> Hi Ken, looks good, it's different to what I was doing last week. My 
> experiments involved allowing $. in class names (or globals), and 
> considering the first part before the period as defining the namespace, 
> sort of fully qualified names for classes. This was following Goran's 
> namespaces ideas. Your approach is also good, and it looks more like 
> what I tried before last week.

Looking at comments and code in Class SharedPool, I see that Juan has 
been doing some experients using SharedPool instances as environments.

The point of releasing this pre-alpha is to be able to discuss various 
approaches with enough concrete details to see the pluses and minuses of 
each.  Now seems like a good time for this.

> I'll try your code today and see how it feels. Looking at the source 
> code it just feels strange that namespaces have colors, hah... I have 
> synesthesia but only with letters and numbers... ;)

My thought is to use a Color swatch/icon to mark Environment Class names 
and have the tooltip give the Environment name prefix.  Use this in 
place of the extended name prefix to reduce clutter.

> Regarding the tools, with my last approach I found I only had to change 
> the rename class and rename global refactorings to consider the case of 
> a class moving from one namespace to another, and everything else 
> seemed to work fine without requiring changes. Also I think you have to 
> make sure to keep associations if they already exist in the 
> environment, for example when renaming a class, so you don't have to 
> recompile methods that use it.

Right.  The UI has to keep the books up to date.

I very much like simple.

My thought again is to allow one to use a Feature (or Feature set) to be 
imported as a (set of) Environment(s).  So Packages can be used either 
way.

More complex UI management, but perhaps simplifies/unifies 
description/usage of Packages.

-KenD