Hi Tony,

if I would implement a hierarchy of environments, I would not exploit "globals" or "declarations" but add "outer" and/or "inner" as instance variables. Then #classNamed: needs to be changed to also look in outer environments. -- I think that environments are already "namespaces". Thus, I would not add an extra subclass "Namespace" for it. 

The second proposal in here is that new syntax via #doesNotUnderstand:. Hmm... I do not like it. :-) Maybe a Environment class >> #fromPath: would work. Then tools can support such a path syntax. In source code I would rather not use it to not create any more "spaghetti code" than we already have. Feels like a "pandoras box" to allow an easy way for arbitrary environments in any piece of code.

Best,
Marcel
Am 25.03.2021 13:58:51 schrieb Tony Garnock-Jones <tonyg at leastfixedpoint.com>:
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210326/b6685924/attachment.html>