[Cuis-dev] [RFI] Environments are Ready For Integration

[Gerald Klix]

On 2020-12-01 17:10, Juan Vuletich wrote:
> On 11/29/2020 12:04 PM, Gerald Klix via Cuis-dev wrote:
>> Hi Juan,
>>
>> is there any chance to get this integrated in the foreseeable future; 
>> e.g. 4 weeks or so?
>>
>>
>> Best Reagrds
>>
>> Gerald
>>
>>
>>
>> On 2020-11-02 21:40, Gerald Klix via Cuis-dev wrote:
>>> Hi all, Hi Juan,
>>>
>>> my change set, that prepares Cuis for environment integration is 
>>> ready for integration.
>>>
>>> I tested it over the
>>> last 3 days, without any environment implementation installed. It 
>>> worked without
>>> errors.
>>>
>>> The git repo is here:
>>> https://gitlab.com/klgcuisstuff/environments
>>>
>>> There is also an Erudite based documentation.
>>>
>>>
>>> Thanks and Best Regards,
>>>
>>> Gerald
> 
> Hi Gerald,
> 
> These changes are rather large and modify Cuis in a lot of places. Most 
> of them are specific to namespaces, and nobody used them as the 
> interface to implement any of the alternative takes on namespaces that 
> were discussed. Therefore we have no validation on how general they 
> might be. So, so far, they are specific to your namespaces 
> implementation. Besides, aside from good discussion, nobody else in the 
> community seems to be working on namespaces or willing to adopt them for 
> their projects. There were voices against namespaces, that I read as 
> "any complexity added to the base image is downside, upside is zero".
IC,ironically Cuis' strive for simplicity made all of this added 
complexity possible. I don't see a chance to achieve the same with Pharo 
or Squeak. So yes, I understand this point.
> 
> Some time ago, in the context of that discussion, I described an 
> approach to namespaces that I'd really like. It is here: 
> https://lists.cuis.st/mailman/archives/cuis-dev/2020-April/001377.html . 
> It is what (I believe) Python and JavaScript are doing. It doesn't seem 
> to me that the changes you suggest would be useful in such approach, as 
> there would not be need for a special "denoting expression".
I can not comment on JavaScript's modules, however I have done several 
custom module importers for Python (e.g. loading modules over an RPC 
library)... In a nutshell: What I have in mind is something like 
python's module system,
with better explicit exports and better integration with the 
package-management-system.

Concerning `denoting expressions`, see this PEP:
https://www.python.org/dev/peps/pep-3155/

What you can learn from this PEP is:
It's hard to get this right from the
(very) beginning. This denotingExpression stuff
is a bit of a clutch, I am inclined to delegate
the whole ClassDescription>>#definition to the meta-class.
> 
> At this point in time it is hard to evaluate the potential upside of 
> integrating your changes, while the extra complexity for a system that 
> doesn't support namespaces is quite apparent.
Yes apparently it is a solution for a problem, only I have or consider 
important.
> 
> Until this changes, I think it is best to keep your changes separate 
> from the base image, to be installed when installing your implementation 
> of namespaces, or working on an alternative one.
Agreed! In the last 9 weeks most of the methods
I patched were not changed, this gives me hope that it remains this way.


Thanks and Best Regards,

Gerald