<div dir="ltr"><div>Hi Ken,<br></div><div>Good, I made the changes to use asEnvironmentName, and fixed all algain to work with packages that define multiple system subcategories. I think it got mixed with an older version at some point before you committed it to github, because some changes that I made to fix the subcategories issues and make it work with my package Domains were missing. Please try filing in from scratch in a new base image, otherwise it gets mixed with other versions.</div><div><br></div><div>See CodePackage>>isolate, it creates an environment if one doesn't already exist, and moves classes to the new environment. Notice I'm using #declare:from:, this moves the associations from the old dictionary to the new dictionary. I avoid creating new associations because it would mess up the CompiledMethods that already have bindings. I also removed instance vars in Environments with references to CodePackages, because I think this is unnecessary.</div><div><br></div><div>These are the basics so far:</div><div><div>- Classes that wish to use classes or other objects of an environment just need to include the environment name in the shared pools in the class declaration;</div><div>- Classes understand the message #environment, answering the first Environment found in their shared pools, or Smalltalk if none is found;<br></div>- You can obtain the package of a class with the message #package (this is already in the base image, I didn't implement this);</div><div>- Analogously, Environments understand the message #package and return the associated package;<br></div><div>- CodePackages understand the messages #environment and #isolate. CodePackage>>environment answers the environment associated with the package, by default it is Smalltalk. CodePackage>>isolate moves the package to a new environment (if the package is already isolated in an Environment, answer its environment).<br></div><div><br></div><div>I'm not very convinced yet of using environments as pools. I think it makes sense to use them like that when you want to import a namespace in a class, but maybe classes should also have a fixed environment associated to them (Smalltalk by default). This would require adding an instance variable 'environment' to Class, and I'm not sure to do that.</div><div><br></div><div><div>I think the next step is more testing, and fixing lots of little things in the tools. For example, class declarations are not possible any more when the superclass is not in Smalltalk, shout paints it red. Also, Browser has methods with references to Smalltalk that should be replaced with 'self environment'.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 12, 2020 at 9:54 AM <<a href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.com</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">On 2020-06-11 13:49, Luciano Notarfrancesco wrote:<br>
<br>
> Cool, thanks.<br>
> <br>
> I just saw some of the latest changes, and I think it will fail with <br>
> packages that define multiple subcategories like I do in Domains: <br>
> 'Domains-Kernel', 'Domains-Groups-Algorithms' and <br>
> 'Domains-Modules-Multivariate' should all end up in the Domains <br>
> environment, that's what the new method <br>
> SystemDictionary>>environmentFromSystemCategory: does. I think we have <br>
> to check all callers of #asIdentifier: and make sure to call this <br>
> method instead, I'll check tomorrow.<br>
<br>
I favor the attached.<br>
<br>
Then try:<br>
  'Morphic-Games-Solitaire' asEnvironmentName asSymbol<br>
<br>
<br>
I am still puzzling out the ChangeSet changes and Class associations in <br>
Smalltalk.<br>
<br>
FYI,<br>
-KenD<br>
</blockquote></div>