Hi Christoph, hi Eliot,

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:

self owner ifNotNil: [:owner | "..."].
self submorphs ifNotEmpty: [:submorphs | "..."].

As alternative names, one could drop their actual "role" and just use their kinds (as generic as desired):

self owner ifNotNil: [:morph | "..."].
self submorphs ifNotEmpty: [:morphs | "..."].
self submorphs ifNotEmpty: [:objects | "..."].


In the past, I happened to mistakenly have used the wrong role, shadowing the right one:

self allOwnersDo: [:owner | "..."].
self allOwnersDo: [:morph | "..."].


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. :-)

***

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.

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.

Best,
Marcel

Am 18.04.2021 05:39:33 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi Christoph,


> On Apr 12, 2021, at 12:32 PM, Christoph Thiede wrote:
>
> Hi Eliot,
>
> I fear that changes like this will not be very durable unless tested in any
> way. At the moment, you won't even notice a new shadow unless you have
> opened a Transcript by accident when accepting a method. Should we maybe
> show a message window for shadows instead when compiled interactively,
> analogously to the warnings about superfluous temps?

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.

>
> (In a larger context, I would strongly opt for (finally) introducing a
> mechanism for linter/compiler annotations in CodeHolders. Most modern
> editors and IDEs have it, even Pharo; if Squeak does not want to get left
> behind, we should support something like this, too. It could or should be
> configurable, of course.)
>
> LBNL, if I understand Chris correctly, "anOwner" might be a suboptimal name
> for a variable that holds Morph instances, right? :)
>
> Best,
> Christoph
>
>
>
> -----
> Carpe Squeak!
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210418/660aae28/attachment.html>