[Cuis-dev] [RFC] Modules/Namespaces for Cuis

[Gerald Klix]

On 2020-10-01 15:19, Juan Vuletich via Cuis-dev wrote:
> On 9/30/2020 4:29 PM, Gerald Klix via Cuis-dev wrote:
>>
>> Hi all, Hi Juan,
>>
>> I looked at Ken's design and some (old) videos and came to the 
>> conclusion, that Ken's package
>> is a nice approach.
>>
>> However I do not like Ken's shared pool implementation and the lack of 
>> means
>> to define classes in environments.
>>
>> Currently I am trying to get rid of the shared pools by using 
>> metaclasses. If this doesn't
>> work I will use an external weak values dictionary, to store the 
>> environment information
>> of a "local" class.
>>
>> To define classes in environments, I am using the a method like this:
>> #subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:environment: 
>>
>> to define a class in an environment. I this needs a specialized 
>> ClassBuilder that does the right thing.
>> Nota bene: If you follow this approach with Ken's
>> implementation as a basis, you will have to do
>> the same.
>>
>> Here the problems start, for example I need to override
>> ClassBuilder>>#privateNewSubclassOf: and
>> ClassBuilder>>#privateNewSubclassOf:from: .
>> In both methods I only need small changes, that are better factored 
>> out into some methods that can be
>> redefined in a specialized class builder.
>>
>> The same is probably true for
>> SystemDictionary>>#at:put: and other methods
>> after all it is the essence of this package,
>> "local" classes are stored somewhere else.
>> (IHMO changing all the places where #at:put: is
>> used to manipulate the binding global variables
>> to classes will be to tedious)
>>
>> *Juan, If I will refactor some classes like ClassBuilder, CodePackage, 
>> SystemDictionary to make the implementation of environments easier,
>> would these changes be accepted into Cuis' core?*
>>
> 
> 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.
> 
> Best if the refactor adds generality, hoping it would also be useful for 
> people trying other approaches too.
> 

Thank you, this is very encouraging!

Obviously the changes will come in tiny
increments, should I post them to the mailing list or should I fork 
Cuis-Smalltalk-Dev
(me hating github:) and post pull-requests?
On a second thought the later won't help
much, because all the core-update files
need renumbering on merge ... Me puzzled ...
Anyways: There will be a constant stream
of patches; that will create a considerable
work load.

BTW: My current efforts -- without any Core refactorings - are here:
https://gitlab.com/klgcuisstuff/environments

>>
>> Best Regards,
>>
>> Gerald
> 
> Cheers,
>