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

[Gerald Klix]

I thought about that and decided against it, because of the following 
drawbacks:

   - Code from other implementations would be harder to adapt to 
environments.
   - Tools writers should not be concerned with environments as long as 
their tools don't deal with managing environments.
   - I am not the most patient person in the world. I want environments 
ASAP.

But I agree: It might turn out that most of the refactorings and other 
things will not work any more. If (I|we) can't make them work, I will 
revert to my original prefix-based proposal.

Now I am also convinced that Juan's proposal, using 
#environmentImplementationIfPresentDo:,
is much better. It should be easy to remove all
the hooks, If my approach does not work,
just by finding all senders of that message.


Best Regards,

Gerald



On 2020-10-06 16:15, Luciano Notarfrancesco via Cuis-dev wrote:
> I think we should think more carefully about this, I'm not sure we really
> need those hooks.
> IMO, if we want to support different implementations of environments, the
> first thing we should do is start by changing the current uses of
> SystemDictionary (like the Browser and other tools), especially the
> references to the global Smalltalk. We could implement #environment in
> Behavior, answering always Smalltalk, and everywhere the global Smalltalk
> is used replace it with 'someClass environment'. And then patiently change
> everything else in the base image that assumes a single global environment
> (for example the change log, refactorings like renaming classes, etc).
> 
> 
> On Tue, Oct 6, 2020 at 2:49 PM Gerald Klix via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
> 
>> On 2020-10-05 21:47, ken.dickey--- via Cuis-dev wrote:
>>> Hi Gerald,
>>>
>>> I am looking at methods in EnvironmentImplementationsDictionary.
>>>
>>> I am confused. Perhaps a class comment could clarify.
>>>
>>> In my mind, one uses Environments (Namespaces) to allow multiple classes
>>> with the same name to exist without problems.
>>>
>>> But looking at (e.g.)
>>>     EnvironmentImplementationsDictionary>>classNamed:
>>> it appears that the first class with some name is returned.
>>>
>>> I would expect something more like a set of (Env->Class) where each
>>> class has the same class name.
>>>
>>> So I am missing something fundamental.
>>>
>>> Can you help me out?
>>>
>>> Thanks much!
>>> -KenD
>>
>> Good Morning Ken,
>>
>> thanks for asking. Obviously my command of English is not good enough to
>> invent self-explanatory names.
>>
>> Its "EnvironmentImplementation*s*Dictionary".
>> 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.
>>
>> Do you have any suggestion for a better
>> name?
>>
>>
>> HTH,
>>
>> Gerald
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
> 
>