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

Juan Vuletich juan at jvuletich.org
Wed Oct 7 07:00:13 PDT 2020


On 10/5/2020 12:40 PM, Gerald Klix via Cuis-dev wrote:
>
>
> On 2020-10-05 17:28, Gerald Klix via Cuis-dev wrote:
>> On 2020-10-05 17:03, Juan Vuletich via Cuis-dev wrote:
>>> On 10/5/2020 7:22 AM, Gerald Klix via Cuis-dev wrote:
>>>> Hi all, hi Juan,
>>>>
>>>> here comes the announced monster change set.
>>>> I hope it "Carries it's own wait."
>>>>
>>>> I added a EnvironmentImplementationDictionary class and changed all 
>>>> relevant methods in SystemDictionary to ask the single instance of 
>>>> EnvironmentImplementationDictionary if some
>>>> implementation can handle the request.
>>>>
>>>> It is the simplest implementation I can think
>>>> of, that is consistent with your statement:
>>>> "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."
>>>>
>>>> Please tell me if this is acceptable or
>>>> to big a change.
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Gerald
>>>
>>> Hi Gerald,
>>>
>>> The size of the change is reasonable. What I'm not sure I like is 
>>> the fact that an instance of EnvironmentImplementationDictionary 
>>> still gets created and its code run even if there are no 
>>> Environments implementations at all. I think it would be better not 
>>> to have the new global, and, for example in #fillCaches, instead of 
>>> what you suggest:
>>>
>>>      self environmentImplementations
>>>          fillClassNameCache: classNames
>>>          andNonClassNameCache: nonClassNames.
>>>
>>> it would be better to do something like:
>>>
>>>      self environmentImplementationIfPresentDo: [ :environments |
>>>          environments
>>>              fillClassNameCache: classNames
>>>              andNonClassNameCache: nonClassNames ].
>>>
>>> and #environmentImplementationIfPresentDo: will only evaluate the 
>>> argument block if there is an environment implementation to delegate 
>>> to. This way EnvironmentImplementationDictionary is no longer needed 
>>> in the base image.
>>>
>>> Thanks,
>>>
>>
>> Hi Juan, Hi all.
>>
>> I started the way you suggested, but I soon came
>> to the conclusion, that this is less readable
>> than the straightforward implementation.
>> I avoids one seemingly useless class
>> for 11 or more methods being more
>> complicated and it might add one more dictionary
>> lookup to all this methods
>> (Hidden behind #environmentImplementationIfPresentDo).
>>
>> I am not sure what the most efficient
>> implementation for the case of
>> "no environment implementations installed" is.
>> If I had to guess, I would suppose it is an 
>> EnvironmentImplementationDictionaryDummy
>> that avoids the (empty) iterations and
>> answers the values for the "nothing found case".
>> (This is based on the assumption that the JIT
>> inlines methods answering constants).
>> If this is the case we can add such a
>> dummy environment implementation manger
>> as an optimization.
>>
>> Perhaps someone with more knowledge about the
>> JIT -- Eliot for example -- can answer this
>> question.
>>
>>
>> Best Regards,
>>
>> Gerald
>>
> On a second thougt:
> Based on the assumption about the JIT, mentioned in my previous email, 
> we could also add an empty
> #environmentImplementationIfPresentDo: method
> and overwrite it in an EnvironmentsBase package.
> The later I am writing right now.

That is a reasonable way.

Let me remark that performance, while nice, is not the top priority. 
Neither it is to make your Environments implementation as legible as 
possible.

The top priority is to make the base image code as readable as possible 
_when there is no Environments implementation present_. People using the 
base image, without any implementation of Environments loaded, should 
not be required to be aware of Environments at all. The hooks should be 
minimal, unobstructive and easy to ignore.

> The various methods in the system dictionary
> will be a bit more complicated, but if the BDFL
> is OK with that, it's certainly OK for me :)

We'll see. I want to keep complexity to a minimum when there are no 
Environments loaded, while allowing for their existance.

> Just my 0.01€,
>
> Gerald
>

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich



More information about the Cuis-dev mailing list