[Cuis-dev] Namespaces?

[Andres Valloud]

... I forgot.  But you may also want to review how the libc guys deal 
with backwards compatibility.  There are tons of smart people "out 
there".  It's not necessary to make everything from scratch again.

On 5/20/19 23:58, Andres Valloud via Cuis-dev wrote:
> I would look at Newspeak to get some ideas.  I'm not so sure about the 
> nested class approach and the default message lookup scheme, but that 
> way of doing things has the benefit of having some serious thought 
> behind it.
> 
> Before doing anything, however, one would have to think what's going to 
> happen when inevitably two packages that should be loaded depend on 
> different versions of a third package.  Or what happens when package A 
> wants to use things from package B that have name collisions with 
> package A.  And how to deal with overrides / redefinitions / 
> refinements.  The etcetera list is longish.  Also, one has to consider 
> how the end result feels, and how people are induced to collaborate as a 
> result.
> 
> So for that, I'd look at Mist.
> 
> None of these problems are easy, and the easy solutions one can think in 
> a day or so tend to have serious side effects that are not immediately 
> visible.  Watch out for the temptation to do something before thinking 
> it through, in the end it causes more problems than it solves.
> 
> On 5/13/19 05:21, Luciano Notarfrancesco via Cuis-dev wrote:
>> Hi everybody,
>> Every now and then I wish we had namespaces. What's the simplest 
>> namespace-like thing that could allows us to simultaneously load two 
>> packages with clashing class names?
>>
>> I've been thinking that it might be reasonable to make packages have 
>> independent namespaces. Nothing complex like VW's, just Smalltalk for 
>> the base image and then a global name in Smalltalk for each package 
>> namespace, and package classes are accessible via sending a message to 
>> its namespace. For example, if Morphic was an external package, 
>> loading it would create a namespace named #Morphic in Smalltalk, and 
>> the classes in the Morphic package would be compiled using this 
>> namespace instead of Smalltalk to lookup globals, and it would 
>> delegate lookups to Smalltalk if it doesn't know the requested keys. 
>> After loading the package you could use the class HandMorph directly 
>> within methods compiled in the Morphic package, but outside of it (in 
>> methods belonging to classes in the base image or in other packages) 
>> you would have to do
>>      Morphic at: #HandMorph
>> or perhaps for convenience as a message like VW:
>>      Morphic HandMorph
>>
>> Has anyone attempted to do anything like this? I just looked around 
>> for five minutes and the impression I get is that it would be 
>> non-trivial, there are a lots of references to Smalltalk and probably 
>> a lot of subtleties to make all the tools work well. What do you think?
>>
>> Thanks,
>> Luciano
>>
>>