[squeak-dev] EnvironmentBrowser and nested Namespaces (was Re: The Inbox: Environments-tonyg.78.mcz)
Tony Garnock-Jones
tonyg at leastfixedpoint.com
Thu Mar 25 12:58:34 UTC 2021
Hi all,
This message is about the in-inbox EXPERIMENTAL DRAFT packages
- http://source.squeak.org/inbox/Environments-tonyg.78.mcz and
- http://source.squeak.org/inbox/Tools-tonyg.1033.mcz
The two packages go together. Screenshot of EnvironmentBrowser in action
attached.
The idea here is a kind of Self-like "namespacing" facility, based
around placing Environment instances into another Environment's globals
table. The EnvironmentBrowser class in Tools 1033 is a sketch of UI for
the core functionality I've identified so far.
If I have the following setup of nested Environments...
Smalltalk -- the normal Environment default / Environment current
- A
- B
- C
- D
with class X in A, class Y in B, a *different* class Y in C, and class Z
in D, then
- In a workspace whose environment is Smalltalk,
`A` evaluates to the environment A.
`A B` evaluates to the environment B.
`A B Y` evaluates to B's Y.
`A C Y` evaluates to C's Y.
etc.
- In a workspace whose environment is A,
all of the examples from the Smalltalk paragraph above are unchanged
`B` evaluates to the environment B,
`B Y` yields B's Y
`C Y` yields C's Y
`D` is an undefined name
- In a workspace whose environment is B,
all of the examples from the Smalltalk paragraph above are unchanged
`Y` is B's Y
`C` and `D` are undefined names
The ability of Environments to import/export is unused (!) at present,
other than Namespace instances default to importing self and Smalltalk.
I'm looking at Monticello now. The major difficulty is that it hardcodes
`Environment current` and expects a single environment to apply.
I imagine the following:
- the nested namespaces are analogous to nested folders in a Unix file
system
- packages are like Debian packages, and may have entries in multiple
namespaces
- `Environment current` at load time acts like a chroot
Given those guesses/assumptions, MC might need to learn about the idea
of classes living in a particular (or more than one!) Environment, and
the necessity of creating Namespaces as needed.
Here's an interesting method on PackageInfo I've been messing around with:
classesAndEnvironments
| cs |
cs := IdentityDictionary new.
self systemCategories do: [:cat |
Environment current namespaceTreeDo: [:environment |
(environment organization listAtCategoryNamed: cat)
do: [:className | | envs |
envs := cs at: (environment valueOf: className)
ifAbsentPut: [Set new].
envs add: environment]]].
^ cs
Does anyone have thoughts on this whole approach? On how MC's model
could profitably be altered to include a notion of namespace/environment?
Regards,
Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Environment Browser on E F: NamespacedExampleClass.png
Type: image/png
Size: 39836 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210325/fa01ee37/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workspace on environment E F.png
Type: image/png
Size: 10583 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210325/fa01ee37/attachment-0003.png>
More information about the Squeak-dev
mailing list
|