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

[Graham Kelly]

On 10/24/20 9:22 AM, Gerald Klix via Cuis-dev wrote:
> On 2020-10-23 17:35, Juan Vuletich via Cuis-dev wrote:
>> On 10/21/2020 1:08 PM, Gerald Klix via Cuis-dev wrote:
>>> 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."
But Cuis should be small...
>>>>>>
>>>>>> 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
>>
>> coreChanges/4393-CuisCore-GeraldKlix-2020Oct07-15h40m-KLG.cs.st
>>
...and this is:
>> Over 60kb of code, 76 methods. 1100 lines of code. I'm sorry, but if 
>> this is the level of impact on the base system that is needed to 
>> support Environments, another approach is needed. Before resorting to 
>> the extreme option of forking Cuis, we might think of some kind of 
>> alert system to warn you if any of the overriden methods gets 
>> modifiend in the base Cuis image. This could also be useful for other 
>> packages that need patching existing methods.
>>
Even my fork of Cuis (with environments) is smaller.
>> Thanks,
>>
> Thanks Juan, for looking at it.
>
> Well, I know. I wrote above:
> "If all works according to my nefarious schemes,
> the environment implementations should know about Cuis' interfaces
> and not the other way around"
> Alas it did not work out, I had to add
> environment aware symbols, so that SystemDictionary can deffer dealing 
> with symbols
> bound to an environments directly to the binding
> environment.
>
> This triggered the next big bunch of changes, to the Browser hierarchy.
> All the browser models that display a class hierarchy do so by 
> creating the list of indented
> class names in the model. IMHO this is not the right thing to do. The 
> model should hold
> a properly sorted list of class name symbols.
> (This change I implemented, I had to).
> The indentation stuff should be done in a specialized list morph. With 
> this refactoring,
> 20 methods (changed and new ones) would be
> unnecessary. That's around 30%.
>
> The remaining stuff falls roughly into three categories:
>
> 1st) Making the compiler ware of the symbols bound in an environment. 
> these are all "bindingOf"-methods in the ClassDescription hierarchy.
> 2nd) All the changes to generate proper definition code for the class 
> and proper
> expression to refer to environment local
> classes.
> 3rd) Make ChangeList, CodeFile and the other classes aware of the 
> extended file in format.
>
> BTW: Some refactorings to CodeFile will be worthwhile. There is a line in
> #classDefinition:with:
> that reads:
> `tokens size = 11 ifFalse:[^doIts add: chgRec].`
> I changed it to:
> `tokens second == #subclass: ifFalse:[ ^ doIts add: chgRec ].`
> Which isn't much better and worse I have no idea
> on how to solve this in a better way.
>
> About our concerns with the size of the change set, I would have 
> reacted in the way. Especially
> there are two additional issues:
> - There are quite a few message sends in the base image, that have no 
> implementation.
> They are all encapsulated in sends to
> #environmentImplementationsIfPresentDo:
> but they will stick out like a Christmas Tree
> on a sunny beach.
> - It changes the fileout/filein machinery.
>
>
> I have some ideas that should make it possible
> to develop major changes to Cuis' core in packages:
However, I did make this:
>
> - We could make a base line of an image,
> by (virtualy) storing all the class definitions
> and method time-stamps in a base line file.
But not all of these:
> - We can implement sort of an ExtensionPackage that contains the base 
> line "entries" of all
> modified classes and methods and bail out
> if one does not match the version in the image
> we file the changes into.
> - We can avoid can replace extension method categories 
> ("*PackageName") with ordinary
> method categories by storing the in a pragma
> and recategorize them after file in. As an added
> bonus we can store the source package of such a method in a method 
> property.
>
Why don't you distribute updates as packages that update the system and 
delete them when done?
> This should make developing core extensions
> in a package safe and should result in a usefully categorized methods.
>
>
> Best Regards,
>
> Gerald
>
>
>
My $0.03,


Graham