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

[Gerald Klix]

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."
 >>>>>
 >>>>> 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
 >
 > 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.
 >
 > 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:

- 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.
- 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.

This should make developing core extensions
in a package safe and should result in a usefully categorized methods.


Best Regards,

Gerald