<div dir="ltr"><div dir="ltr">On Mon, May 13, 2019 at 8:02 PM ken.dickey--- via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">One thought is to have a "package namespace variable" which can be set in the code browser.<br><div class="gmail-m_8031024211793727772pre" style="margin:0px;padding:0px;font-family:monospace"> <br> The default would be #Smalltalk (and associated intern dictionary), but setting a package namespace could cause all code to be recompiled to use the package's internal intern dictionary.  The code browser would make new method names be interned in the current package namespace (-> use package intern dictionary).<br> <br></div></div></blockquote><div><br></div><div>The idea seems very powerful and it is tempting to take it all the way and use it for for method selectors too. But it seems to me it could get very complex. In a first try I would use it only for class names, to isolate classes defined within a package. just to solve the problem of having 2 packages defining classes with the
 same name, or a package that defines a class with a name that already 
exists in the base image. For example, changing the method subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: to automatically deduce the package where the class name should be internalized from the category name, or perhaps extend the keyword to include a namespace: after category:. But this already gets a little complicated, you have to consider what happens when you move a class to another category...</div><div><br></div></div></div>