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

[Gerald Klix]

On 2020-10-07 17:44, Gerald Klix via Cuis-dev wrote:
> On 2020-10-07 16:07, Juan Vuletich via Cuis-dev wrote:
>> On 10/7/2020 3:19 AM, Gerald Klix via Cuis-dev wrote:
>>> On 2020-10-06 21:29, ken.dickey at whidbey.com wrote:
>>>> On 2020-10-06 08:52, Gerald Klix wrote:
>>>>
>>>>> Please bear with me until I can provide a simple example
>>>>> implementation that handles environments.
>>>>
>>>> Gerald,
>>>>
>>>> Thanks much for this quick response.
>>>>
>>>> I am not the world's brightest light, so sometimes it takes me a 
>>>> while to get things.
>>>>
>>>> Also, apologies for not yet completing my PackageEnvironments 
>>>> proposal. You are motivating me to get back to it.
>>>>
>>>> With so many ways to implement Namespaces/Environments, it is good 
>>>> to have a number of concrete implementations to explore to find/get 
>>>> the best outcomes.
>>>>
>>>> I am very much looking forward to the fruits of your efforts!
>>>>
>>>> Good on ya,
>>>> -KenD
>>>>
>>>
>>> Good Morning Ken,
>>>
>>> Mentioning your PackageEnvironments approach motivates me to try 
>>> again explaining ths
>>> EnvironmentImplementationsDictionary thing:
>>>
>>> Suppose we have two packages (or set of packages) that implement 
>>> environments.
>>> One is your "package environments (PS) implementation", the other one 
>>> a simple environment implementation (SE).
>>> Both implementations should provide
>>> a so called environment manager singleton,
>>> that manages their implementation's environments. These managers 
>>> should be registered with the EnvironmentImplementationsDictionary 
>>> singleton.
>>> Of course both must implement the protocol
>>> demanded by this class.
>>> This way two our more environment implementations can coexist in one 
>>> Cuis image.
>>>
>>> I tried to implement Juan's (soft) requirement:
>>> "
>>> Yes. I want Cuis to be a good place for doing any kinds of 
>>> experiments. Adding hooks for optional pluggable behavior is a big 
>>> part of that."
>>>
>>> You can look at
>>> https://gitlab.com/klgcuisstuff/environments/-/blob/master/EnvironmentsBase.pck.st 
>>>
>>>
>>> and
>>>
>>> https://gitlab.com/klgcuisstuff/environments/-/blob/master/SimpleEnvironments.pck.st 
>>>
>>>
>>> to get the details.
>>> Please don't file these packages in, they are
>>> currently broken.
>>>
>>>
>>> HTH and Best Regards,
>>>
>>> Gerald
>>
>> If this implies the base image (and people using it) to be aware of 
>> many possible implementations of environments, and include the 
>> complexity required to make them work smoothly together, then this 
>> sounds like too much to me.
>>
>> If this is really required, maybe it should go into a 
>> MultiEnvironmentsImplementationsSupport.pck.st, or such. Maybe people 
>> working on varios implementations of Environments could get together 
>> to work on this package. And please, make it require as little as 
>> possible from the base image. A few methods delegating to (most likely 
>> absent) optional service is ok. Knowledge of all the complexity of 
>> MultiEnvironmentsImplementationsSupport.pck.st in the base image, is not.
>>
>> Thanks,
>>
> Juan,
> 
> If all works according to my nefarious schemes,
> the environment implementations should know about Cuis' interfaces and 
> not the other way around.
> I started an EnvironmentsBase.pck.st, with the intention to move 
> everything, which is not strictly required in the base image into it;
> especially this (in)famous EnvironmentImplementationsDictionary.
> It contains an abstract super class
> for an environment manager documenting Cuis' interface to it.
> 
> In a nutshell: I had the same idea.
> 
> However some additional changes in
> ClassDescription>>definition will
> be necessary (obviously).
> 
> 
> HTH and Best Regards,
> 
> Gerald

Good Evening Everyone,

I now have beta of the environment stuff ready.
Documentation is currently missing (Use the Source, Luke). I will start 
writing some tomorrow.

The whole thing can be found at:
https://gitlab.com/klgcuisstuff/environments

If you want to test it just clone this repo.
File in
coreChanges/4393-CuisCore-GeraldKlix-2020Oct07-15h40m-KLG.cs.st
first. Then file in the SimpleEnvironments package. This package 
contains a very simple
environment implementation, that is neither aware of package or 
categories, meaning
categories and environments are orthogonal
wrt. simple environments.
Of course the environment
framework permits other implementations.


Have Fun and Best Regards,

Gerald