[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