<div dir="ltr"><div>Yes, "namespaces" are a slippery slope that very quickly derives in all that... packages with inter-dependencies, simultaneously having different versions of a class or even its methods running in a single system, etc. Those are very hard issues and people have been working on that for a long time. I'm not sure I would want to solve those problems in Cuis anyways, it might be cool, it might also be complex and tedious, I don't know.<br></div><div><br></div><div>The only problem I would like to solve is, given a package that defines *new* classes, loading it not globally in Smalltalk but locally in a new "SystemDictionary". Everything else is "out of scope" for me. So far, Environments looks very close to what I want. I'm not sure yet if it would work, or if it would have any side effect I'm not seeing... when I get some free time I'll try to port it as a Cuis package, and I'll see how it feels using it in my projects and maybe get a better understanding of the issues. But I certainly wouldn't want to implement some idea of "namespaces" in a hurry and integrate it in the base image.<br></div><div><br></div><div>Mist and Newspeak are interesting but... I'm a Smalltalk-80 guy... I guess I'm a traditionalist after all... I'll look at them for ideas, tho.<br></div><div><br></div><div>I'd like to hear what people like and dislike of other namespace systems. Did anyone ever use namespaces in VW? Is there something bad about them?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 21, 2019 at 7:07 AM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">... I forgot.  But you may also want to review how the libc guys deal <br>
with backwards compatibility.  There are tons of smart people "out <br>
there".  It's not necessary to make everything from scratch again.<br>
<br>
On 5/20/19 23:58, Andres Valloud via Cuis-dev wrote:<br>
> I would look at Newspeak to get some ideas.  I'm not so sure about the <br>
> nested class approach and the default message lookup scheme, but that <br>
> way of doing things has the benefit of having some serious thought <br>
> behind it.<br>
> <br>
> Before doing anything, however, one would have to think what's going to <br>
> happen when inevitably two packages that should be loaded depend on <br>
> different versions of a third package.  Or what happens when package A <br>
> wants to use things from package B that have name collisions with <br>
> package A.  And how to deal with overrides / redefinitions / <br>
> refinements.  The etcetera list is longish.  Also, one has to consider <br>
> how the end result feels, and how people are induced to collaborate as a <br>
> result.<br>
> <br>
> So for that, I'd look at Mist.<br>
> <br>
> None of these problems are easy, and the easy solutions one can think in <br>
> a day or so tend to have serious side effects that are not immediately <br>
> visible.  Watch out for the temptation to do something before thinking <br>
> it through, in the end it causes more problems than it solves.<br>
> <br>
> On 5/13/19 05:21, Luciano Notarfrancesco via Cuis-dev wrote:<br>
>> Hi everybody,<br>
>> Every now and then I wish we had namespaces. What's the simplest <br>
>> namespace-like thing that could allows us to simultaneously load two <br>
>> packages with clashing class names?<br>
>><br>
>> I've been thinking that it might be reasonable to make packages have <br>
>> independent namespaces. Nothing complex like VW's, just Smalltalk for <br>
>> the base image and then a global name in Smalltalk for each package <br>
>> namespace, and package classes are accessible via sending a message to <br>
>> its namespace. For example, if Morphic was an external package, <br>
>> loading it would create a namespace named #Morphic in Smalltalk, and <br>
>> the classes in the Morphic package would be compiled using this <br>
>> namespace instead of Smalltalk to lookup globals, and it would <br>
>> delegate lookups to Smalltalk if it doesn't know the requested keys. <br>
>> After loading the package you could use the class HandMorph directly <br>
>> within methods compiled in the Morphic package, but outside of it (in <br>
>> methods belonging to classes in the base image or in other packages) <br>
>> you would have to do<br>
>>      Morphic at: #HandMorph<br>
>> or perhaps for convenience as a message like VW:<br>
>>      Morphic HandMorph<br>
>><br>
>> Has anyone attempted to do anything like this? I just looked around <br>
>> for five minutes and the impression I get is that it would be <br>
>> non-trivial, there are a lots of references to Smalltalk and probably <br>
>> a lot of subtleties to make all the tools work well. What do you think?<br>
>><br>
>> Thanks,<br>
>> Luciano<br>
>><br>
>><br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>