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

[Gerald Klix]

On 2020-10-06 17:00, ken.dickey--- via Cuis-dev wrote:
> 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

Ken,

Obviously I still haven't made myself clear.
Please bear with me until I can provide a simple example implementation 
that handles environments. I will have to reimplement my proposed change 
set, because I came to the conclusion, that Juan's approach is much better.

I am sure, that all your goals will be met.

Best Regards,

Gerald