No great difference there: if your demo or example code were an instance,
myThing might also have been the result of `self thing`. ;-)

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

> 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>:
>
>> 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/7516625a/attachment.html>