[Cuis-dev] [RFC] Namespaces, changes to SystemDictionary, Object and a dictionary class for tracking environment implementations

[ken.dickey at whidbey.com]

On 2020-10-05 23:49, Gerald Klix wrote:
> On 2020-10-05 21:47, ken.dickey--- via Cuis-dev wrote:
..
>> In my mind, one uses Environments (Namespaces) to allow multiple 
>> classes with the same name to exist without problems.
..

> Each environment implementation - yours, mine, anybody's -- should
> register an instance of a environment manager class with this
> dictionary, which in turn, dispatches most of SystemDictionary's
> retrieving and helper
> methods to various environment *implementations*. In many cases the 
> first
> answer is taken.
> 
> Clearly if two environment implementations
> manage an environment and a class with the same names each -- what a
> "name" is, is up the implementation -- we have a conflict,
> but I presume this will happen seldomly.

OK.  We have very different views about Environments/Namespaces.

 From https://github.com/KenDickey/PackageEnvironments README.md
==vv==
Goals:
- Multiple Classes with same name coexist in different package 
environments
- Unburden Smalltalk SystemDictionary by reducing the number of 
helper/support class names

Weak Goals:
- Cuis users won't notice until they need it
- Introduce fewest new concepts and mechanisms
- Work as expected with current tools
==^^==

And from the section "The Story So Far"
==vvv==
Tools:
- Class & Hierarchy Browsers, Package Browser, ChangeSorter, Debugger 
seem to work OK.
- Package Save/FileOut working (same for Feature or Environment).
- ChangeSets seem OK.
- Packages which create multiple Categories seem OK.
- Find Class works in (System) Browser.
==^^^==

Most of the work so far has been teaching tools to look up 
classes/methods in the object's #environment (a method that returns 
either an Environment or the value of Smalltalk).

Aside from visibility, Environments and Packages are the same, so the 
concept of a packaged Feature does not change.

Also, when a package is loaded, if it requires any packages which are 
Environments, it "uses" them, meaning that their names are visible to 
the using Environment.

===
It seems that your proposed changes satisfy neither of the major goals 
that I was looking for.

The basic questions I have are:
- What is your goal set?
- How does this help me?
- Does the result carry its weight?
===

Sorry to come down on you with a hammer, but without answers to these 
questions I really don't know what you are proposing.

Note that I do a number of experiments, many of which I throw away.

Don't let me talk you out of exploring an experimenting.  I get many 
half or quarter baked ideas and until I build things I don't fully 
understand some of them.  Building things is good.  Sharing is good.

Part of sharing is sharing of the ideas and context, and I am just not 
getting it.  Can you help me out here?

Thanks a bunch!
-KenD