Also possible. :-) Whereas personally, I associate the "my" prefix with demo and example code but not production. :-)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <jakres+squeak at gmail.com>
Gesendet: Montag, 19. April 2021 19:46:40
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Shadows (was: The Trunk: Morphic-eem.1742.mcz)

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<mailto: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<mailto: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<mailto: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/5970facb/attachment.html>