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

[Gerald Klix]

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