<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Christoph, hi Eliot,<div><br></div><div>it might be that the likelihood of shadowing increases with the use of cull'ed block invocations, which we have been supporting more and more in the last years:</div><div><br></div><div>self owner ifNotNil: [:owner | "..."].</div><div>self submorphs ifNotEmpty: [:submorphs | "..."].</div><div><br></div><div>As alternative names, one could drop their actual "role" and just use their kinds (as generic as desired):</div><div><br></div><div><div>self owner ifNotNil: [:morph | "..."].</div><div>self submorphs ifNotEmpty: [:morphs | "..."].</div></div><div>self submorphs ifNotEmpty: [:objects | "..."].<br></div><div><br></div><div>In the past, I happened to mistakenly have used the wrong role, shadowing the right one:</div><div><br></div><div>self allOwnersDo: [:owner | "..."].</div><div>self allOwnersDo: [:morph | "..."].<br></div><div><br></div><div>Yet, we do have misleading protocol on what to actually call "owner." Just the morph that has me directly in its submorphs? That might be another topic. :-)</div><div><br></div><div>***</div><div><br></div><div>To avoid shadowing, I find myself using (a) abbreviations, (b) kind/class, or (c) count-prefix "a" or "some". Or a combination of those. Unfortunately, omitting the domain-specific role in a name might impair readability.</div><div><br></div><div>I just noticed that I am finde with "aMorph" as a method argument, yet I would never use "a" in a block argument. :-D Strange.</div><div><br></div><div>Best,</div><div>Marcel</div><div><br></div><div class="mb_sig"></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 18.04.2021 05:39:33 schrieb Eliot Miranda <eliot.miranda@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Christoph,<br><br><br>> On Apr 12, 2021, at 12:32 PM, Christoph Thiede <christoph.thiede@student.hpi.uni-potsdam.de> wrote:<br>> <br>> Hi Eliot,<br>> <br>> I fear that changes like this will not be very durable unless tested 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 ing s from the compiler in the update stream and replaced shadowed temp cars by renamed temp vars.  So my changes have no semantic effect 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 left<br>> behind, we should support something like this, too. It could or should be<br>> configurable, of course.)<br>> <br>> LBNL, if I understand Chris correctly, "anOwner" might be a 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></christoph.thiede@student.hpi.uni-potsdam.de></div></blockquote></div>