In this particular case, I would suggest myOwner, mySubmorphs.

Am Mo., 19. Apr. 2021 um 19:43 Uhr schrieb Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de>:

> Hi Eliot, hi Marcel,
>
>
> > I’m removing shadows, not adding new ones.
>
>
> I do not doubt this. I only wanted to point to the fact that your
> refactoring is completely free of safety. If someone else says, "Hey, these
> names are too long, let's shorten them", then the shadows might be
> introduced again and no one will notice. A change in tooling could prevent
> this problem; otherwise, automated tests would do, too. Just a notice. :-)
>
>
> > 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.
>
> +1. I also use roles as names (but I do not really like it - these are not
> really explaining names). Abbreviations are counter-intuitive, too. Another
> option is "ea", but this only good for very small methods, if at all. I use
> "some" analogously to "a" for method parameters that should be collections.
> Maybe "the" might be a better pattern for naming block args? :-)
>
> > self owner ifNotNil: [:theOwner | "..."].
> > self submorphs ifNotEmpty: [:theSubmorphs | "..."].
>
> Best,
> Christoph
>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> *Gesendet:* Sonntag, 18. April 2021 14:44:32
> *An:* squeak-dev
> *Betreff:* Re: [squeak-dev] Shadows (was: The Trunk: Morphic-eem.1742.mcz)
>
> 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/20210419/01e88dc6/attachment.html>