[Cuis-dev] Namespace Code Sketch
Luciano Notarfrancesco
luchiano at gmail.com
Fri Jun 12 02:57:48 PDT 2020
Hi Ken,
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.
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.
These are the basics so far:
- 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;
- Classes understand the message #environment, answering the first
Environment found in their shared pools, or Smalltalk if none is found;
- You can obtain the package of a class with the message #package (this is
already in the base image, I didn't implement this);
- Analogously, Environments understand the message #package and return the
associated package;
- 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).
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.
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'.
On Fri, Jun 12, 2020 at 9:54 AM <ken.dickey at whidbey.com> wrote:
> On 2020-06-11 13:49, Luciano Notarfrancesco wrote:
>
> > Cool, thanks.
> >
> > I just saw some of the latest changes, and I think it will fail with
> > packages that define multiple subcategories like I do in Domains:
> > 'Domains-Kernel', 'Domains-Groups-Algorithms' and
> > 'Domains-Modules-Multivariate' should all end up in the Domains
> > environment, that's what the new method
> > SystemDictionary>>environmentFromSystemCategory: does. I think we have
> > to check all callers of #asIdentifier: and make sure to call this
> > method instead, I'll check tomorrow.
>
> I favor the attached.
>
> Then try:
> 'Morphic-Games-Solitaire' asEnvironmentName asSymbol
>
>
> I am still puzzling out the ChangeSet changes and Class associations in
> Smalltalk.
>
> FYI,
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200612/e6cde413/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: System-Environments.pck.st
Type: application/octet-stream
Size: 6977 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200612/e6cde413/attachment-0001.obj>
More information about the Cuis-dev
mailing list