<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">

                                        Hi Tony,<div class="mb_sig"></div>

                                        <div><br></div><div>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. --<span style="font-size: 10pt"> I think that environments are already "namespaces". Thus, I would not add an extra subclass "Namespace" for it. </span></div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Marcel</div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">

                        <p style="color: #AAAAAA; margin-top: 10px;">Am 25.03.2021 13:58:51 schrieb Tony Garnock-Jones <tonyg@leastfixedpoint.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi all,

<br>

<br>This message is about the in-inbox EXPERIMENTAL DRAFT packages

<br>

<br>  - http://source.squeak.org/inbox/Environments-tonyg.78.mcz and

<br>  - http://source.squeak.org/inbox/Tools-tonyg.1033.mcz

<br>

<br>The two packages go together. Screenshot of EnvironmentBrowser in action 

attached.

<br>

<br>The idea here is a kind of Self-like "namespacing" facility, based 

<br>around placing Environment instances into another Environment's globals 

<br>table. The EnvironmentBrowser class in Tools 1033 is a sketch of UI for 

the core functionality I've identified so far.

<br>

If I have the following setup of nested Environments...

<br>

<br>   Smalltalk   -- the normal Environment default / Environment current

<br>     - A

<br>       - B

<br>       - C

<br>     - D

<br>

<br>with class X in A, class Y in B, a *different* class Y in C, and class Z 

<br>in D, then

<br>

<br>  - In a workspace whose environment is Smalltalk,

<br>     `A` evaluates to the environment A.

<br>     `A B` evaluates to the environment B.

<br>     `A B Y` evaluates to B's Y.

<br>     `A C Y` evaluates to C's Y.

<br>     etc.

<br>

<br>  - In a workspace whose environment is A,

<br>     all of the examples from the Smalltalk paragraph above are unchanged

<br>     `B` evaluates to the environment B,

<br>     `B Y` yields B's Y

<br>     `C Y` yields C's Y

<br>     `D` is an undefined name

<br>

<br>  - In a workspace whose environment is B,

<br>     all of the examples from the Smalltalk paragraph above are unchanged

<br>     `Y` is B's Y

<br>     `C` and `D` are undefined names

<br>

<br>The ability of Environments to import/export is unused (!) at present, 

other than Namespace instances default to importing self and Smalltalk.

<br>

<br>I'm looking at Monticello now. The major difficulty is that it hardcodes 

`Environment current` and expects a single environment to apply.

<br>

<br>I imagine the following:

<br>

<br>  - the nested namespaces are analogous to nested folders in a Unix file

<br>    system

<br>

<br>  - packages are like Debian packages, and may have entries in multiple

<br>    namespaces

<br>

<br>  - `Environment current` at load time acts like a chroot

<br>

<br>Given those guesses/assumptions, MC might need to learn about the idea 

<br>of classes living in a particular (or more than one!) Environment, and 

the necessity of creating Namespaces as needed.

<br>

<br>Here's an interesting method on PackageInfo I've been messing around with:

<br>

<br>   classesAndEnvironments

<br>     | cs |

<br>     cs := IdentityDictionary new.

<br>     self systemCategories do: [:cat |

<br>       Environment current namespaceTreeDo: [:environment |

<br>        (environment organization listAtCategoryNamed: cat)

<br>          do: [:className | | envs |

<br>            envs := cs at: (environment valueOf: className)

ifAbsentPut: [Set new].

envs add: environment]]].

<br>     ^ cs

<br>

<br>Does anyone have thoughts on this whole approach? On how MC's model 

could profitably be altered to include a notion of namespace/environment?

<br>

<br>Regards,

<br>   Tony

<br><br></div></blockquote></div>