<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>-1 on the #doesNotUnderstand: proposal. JsonObject is already questionable depending on the use case - IMHO message forwarding is easy to abuse, and using it for any kind of lookup appears kind of abusive to me. However, only my 2 cents. :-)</p>
<p><br>
</p>
<p>A big +1 for the rest of the proposed changes! :-)</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div class="_rp_U4 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass" id="Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Freitag, 26. März 2021 11:42:24<br>
<b>An:</b> squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] EnvironmentBrowser and nested Namespaces (was Re: The Inbox: Environments-tonyg.78.mcz)</font>
<div> </div>
</div>
<div>
<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 <br>
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 <br>
the core functionality I've identified so far. <br>
<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, <br>
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 <br>
`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 <br>
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) <br>
ifAbsentPut: [Set new]. <br>
envs add: environment]]]. <br>
^ cs <br>
<br>
Does anyone have thoughts on this whole approach? On how MC's model <br>
could profitably be altered to include a notion of namespace/environment? <br>
<br>
Regards, <br>
Tony <br>
<br>
</div>
</blockquote>
</div>
</div>
</body>
</html>