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

[Gerald Klix]

On 2020-10-28 22:12, Graham Kelly via Cuis-dev wrote:
> 
> 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
> 

Dear Graham,

Do you mind to show us your fork of Cuis?


Best Regards,

Gerald