<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Tony,<div><br></div><div>thanks for this example. :-)</div><div><br></div><div>> <span style="font-size: 10pt">I could use a DynamicVariable, but it seems a bit of a shame to use such</span></div><span style="font-size: 10pt">> a big hammer to (poorly?) simulate what lexical scope gives for free.</span><div class="mb_sig"></div>
<div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Hmm.... I wonder if that would be actually a "big hammer" or just an indication that you favor larger pieces of code (i.e. long methods) over short ones. In modules composed of many short(-ish) methods, I tend to focus on object messaging and higher-level control flow. There, I do not think about lexical scoping as an important design element.</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">In Vivide, I use DynamicVariable to scope relevant domain objects (i.e. active vivide, active profile, active organization, active script, ...). :-)</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">(I noticed that Newspeak puts a stronger focus on lexical scoping than Squeak/Smalltalk does.)</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Best,</span></div><div><span style="font-size: 10pt">Marcel</span></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 19.04.2021 10:36:53 schrieb Tony Garnock-Jones <tonyg@leastfixedpoint.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi all,<br><br>Slight tangent - I wanted to show a place where I actively want to be <br>able to shadow variables lexically.<br><br>I am working with an Actor DSL that expands to use of a "well-known" <br>local variable called "thisTurn". Here's an example of the kind of <br>expanded code I want to be able to have:<br><br> thisTurn spawn: [:thisTurn |<br><br> "NB. thisTurn here is in a different Actor's context to<br> the thisTurn that had #spawn: sent to it!"<br><br> thisTurn assert: (Presence new userName: 'me').<br> thisTurn assert: (Observe new<br> label: #Presence;<br> observer: (thisTurn ref<br> onAsserted: [:thisTurn :p :handle |<br> "Similarly, thisTurn here is the turn active at the<br> time an asserted event matching the given label is<br> processed, not the time that the Observe assertion is<br> made."<br><br> "..."];<br> onRetracted: [:thisTurn :handle |<br> "..."]))]<br><br>The idea is that thisTurn should represent the <br>ambiently-active-and-current Turn at the time each little fragment of <br>code runs.<br><br>I could use a DynamicVariable, but it seems a bit of a shame to use such <br>a big hammer to (poorly?) simulate what lexical scope gives for free.<br><br>TL;DR: To this old functional programmer, shadowing within a method <br>isn't an error, but is instead useful.<br><br>Now that we have had proper lexical closures for quite a few years, <br>could we consider lifting the restriction on shadowing? I'm aware there <br>would likely be social obstacles to doing so; would there also be <br>technical obstacles?<br><br>Cheers,<br> Tony<br><br><br><br><br>On 4/18/21 2:44 PM, Marcel Taeumel wrote:<br>> Hi Christoph, hi Eliot,<br>> <br>> it might be that the likelihood of shadowing increases with the use of <br>> cull'ed block invocations, which we have been supporting more and more <br>> in the last years:<br>> <br>> self owner ifNotNil: [:owner | "..."].<br>> self submorphs ifNotEmpty: [:submorphs | "..."].<br>> <br>> As alternative names, one could drop their actual "role" and just use <br>> their kinds (as generic as desired):<br>> <br>> self owner ifNotNil: [:morph | "..."].<br>> self submorphs ifNotEmpty: [:morphs | "..."].<br>> self submorphs ifNotEmpty: [:objects | "..."].<br>> <br>> In the past, I happened to mistakenly have used the wrong role, <br>> shadowing the right one:<br>> <br>> self allOwnersDo: [:owner | "..."].<br>> self allOwnersDo: [:morph | "..."].<br>> <br>> Yet, we do have misleading protocol on what to actually call "owner." <br>> Just the morph that has me directly in its submorphs? That might be <br>> another topic. :-)<br>> <br>> ***<br>> <br>> To avoid shadowing, I find myself using (a) abbreviations, (b) <br>> kind/class, or (c) count-prefix "a" or "some". Or a combination of <br>> those. Unfortunately, omitting the domain-specific role in a name might <br>> impair readability.<br>> <br>> I just noticed that I am finde with "aMorph" as a method argument, yet I <br>> would never use "a" in a block argument. :-D Strange.<br>> <br>> Best,<br>> Marcel<br>> <br>>> Am 18.04.2021 05:39:33 schrieb Eliot Miranda <eliot.miranda@gmail.com>:<br>>><br>>> Hi Christoph,<br>>><br>>><br>>> > On Apr 12, 2021, at 12:32 PM, Christoph Thiede wrote:<br>>> ><br>>> > Hi Eliot,<br>>> ><br>>> > I fear that changes like this will not be very durable unless tested <br>>> in any<br>>> > way. At the moment, you won't even notice a new shadow unless you have<br>>> > opened a Transcript by accident when accepting a method. Should we maybe<br>>> > show a message window for shadows instead when compiled interactively,<br>>> > analogously to the warnings about superfluous temps?<br>>><br>>> I’m removing shadows, not adding new ones. In all cars I saw eleven <br>>> ing s from the compiler in the update stream and replaced shadowed <br>>> temp cars by renamed temp vars. So my changes have no semantic effect <br>>> and only remove the warning.<br>>><br>>> ><br>>> > (In a larger context, I would strongly opt for (finally) introducing a<br>>> > mechanism for linter/compiler annotations in CodeHolders. Most modern<br>>> > editors and IDEs have it, even Pharo; if Squeak does not want to get <br>>> left<br>>> > behind, we should support something like this, too. It could or <br>>> should be<br>>> > configurable, of course.)<br>>> ><br>>> > LBNL, if I understand Chris correctly, "anOwner" might be a <br>>> suboptimal name<br>>> > for a variable that holds Morph instances, right? :)<br>>> ><br>>> > Best,<br>>> > Christoph<br>>> ><br>>> ><br>>> ><br>>> > -----<br>>> > Carpe Squeak!<br>>> > --<br>>> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br>>> ><br>>><br>> <br>> <br><br></eliot.miranda@gmail.com></div></blockquote></div>