<div><div><div dir="auto">Hi Ken, looks good, it’s different to what I was doing last week. My experiments involved allowing $. in class names (or globals), and considering the first part before the period as defining the namespace, sort of fully qualified names for classes. This was following Goran’s namespaces ideas. Your approach is also good, and it looks more like what I tried before last week.</div><div dir="auto"><br></div><div dir="auto">I’ll try your code today and see how it feels. Looking at the source code it just feels strange that namespaces have colors, hah... I have synesthesia but only with letters and numbers... ;)</div><div dir="auto"><br></div><div dir="auto">Regarding the tools, with my last approach I found I only had to change the rename class and rename global refactorings to consider the case of a class moving from one namespace to another, and everything else seemed to work fine without requiring changes. Also I think you have to make sure to keep associations if they already exist in the environment, for example when renaming a class, so you don’t have to recompile methods that use it.</div></div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 10 Jun 2020 at 9:46 PM, ken.dickey--- via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Greetings,<br>
<br>
I have done enough playtime to want to share a "technology preview"<br>
<br>
   <a href="https://github.com/KenDickey/PackageEnvironments" rel="noreferrer" target="_blank">https://github.com/KenDickey/PackageEnvironments</a><br>
<br>
As many of you have played around with this already, the idea is avoid <br>
name collisions when loading multiple packages with the same Class <br>
names, e.g. to have multiple kinds of card games from different authors <br>
within the same image.  The gist is to have Environments for Class name <br>
lookup which do not register the class names in the Smalltalk <br>
dictionary.<br>
<br>
To make this "the Cuis Way", there is a 'System-Environments' Feature, <br>
so no one has to use Environments.  Only if you want/need them.<br>
<br>
The idea is that instead of<br>
   Feature require: 'MyCoolFeature'.<br>
one does<br>
   Environment fromFeature: 'MyCoolFeature'.<br>
and everything just works.<br>
<br>
I have only done the bit of converting a loaded CodePackage, but wanted <br>
to get the ideas out to see if perhaps there is interest in helping me <br>
complete this.<br>
<br>
In particular, the refactoring and other tools will need some tweaks.<br>
<br>
Notes are in the README.md in the PackageEnvironments repo.<br>
<br>
Any way, I think things are simple enough to benefit from some early <br>
feedback.<br>
<br>
Not yet a complete solution, but I wanted to share before things got <br>
complex.<br>
<br>
As you may know, my motto is "If I make it simple enough, even I can <br>
implement it".  ;^)<br>
<br>
Enjoy Cuis!!<br>
-KenD<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></div>
</div>