[Cuis-dev] [RFC] Namespaces, changes to SystemDictionary, Object and a dictionary class for tracking environment implementations
cuis.01 at klix.ch
Wed Oct 7 08:44:46 PDT 2020
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.
>>> 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,
>> 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
>> 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
>> 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
>> to get the details.
>> Please don't file these packages in, they are
>> currently broken.
>> HTH and Best Regards,
> 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.
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
be necessary (obviously).
HTH and Best Regards,
More information about the Cuis-dev