Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123158
Precedence: bulk
MIME-Version: 1.0
References: <792b2282-b7a3-40dd-899c-daab55353316@bastelstu.be>
 <f7efdf8c-826f-460e-80c0-53f4ca27e8cb@bastelstu.be> <08200b2f-55ca-4e8f-aeb3-d5b07bf3ae3c@scriptfusion.com>
In-Reply-To: <08200b2f-55ca-4e8f-aeb3-d5b07bf3ae3c@scriptfusion.com>
Date: Fri, 19 Apr 2024 21:08:44 +0200
Message-ID: <CANS-=peccUSd-YeUH-txbmsQHeGXgxQphaXb0V5vAxEyWOiPYw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names
To: Bilge <bilge@scriptfusion.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a3dc96061677d2fb"
From: kjarli@gmail.com (Lynn)

--000000000000a3dc96061677d2fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 19, 2024 at 8:50=E2=80=AFPM Bilge <bilge@scriptfusion.com> wrot=
e:

> On 19/04/2024 18:42, Tim D=C3=BCsterhus wrote:
>
> The two weeks of discussion are over now, the RFC didn't receive any
> substantial changes after the initial proposal, and neither was there any
> significant content-related feedback after the first few days.
>
> As such, I plan to open the vote early next week without making further
> changes to the RFC text.
>
> Best regards
> Tim D=C3=BCsterhus
>
> Hi Tim,
>
> Not that my opinion counts for much, but I have to say I find this very
> odd.
>
> Good class names:
> Id // Identifier
> ID // Identity Document
>
> I understand the distinction you wish to make here, between an acronym an=
d
> abbreviation, but I think it's a meaningless distinction. In this case,
> `Id` would be fine for "identifier", but "Identity Document" should simpl=
y
> be `IdentityDocument`. Whilst the distinction may seem meaningful to you,
> it certainly does not look that way to me; I think it would be difficult =
to
> remember and explain to someone else. Perhaps the tie breaker could be th=
at
> it wouldn't be meaningful to an automated style checker, either. That is,
> it would be difficult to enforce this policy exception in any automated
> way. Why not just keep it simple and consistent here, disallowing runs of
> multiple upper-case letters?
>
> Cheers,
> Bilge
>
I was under the impression that this RFC was trying to solve exactly that,
so I'm surprised to see that ID would be allowed.

--000000000000a3dc96061677d2fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 19, 2024 at 8:50=E2=80=AF=
PM Bilge &lt;<a href=3D"mailto:bilge@scriptfusion.com">bilge@scriptfusion.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 19/04/2024 18:42, Tim D=C3=BCsterhus
      wrote:<br>
    </div>
    <blockquote type=3D"cite">The
      two weeks of discussion are over now, the RFC didn&#39;t receive any
      substantial changes after the initial proposal, and neither was
      there any significant content-related feedback after the first few
      days.
      <br>
      <br>
      As such, I plan to open the vote early next week without making
      further changes to the RFC text.
      <br>
      <br>
      Best regards
      <br>
      Tim D=C3=BCsterhus
      <br>
    </blockquote>
    <p>Hi Tim,</p>
    <p>Not that my opinion counts for much, but I have to say I find
      this very odd.</p>
    <pre>Good class names:
Id // Identifier
ID // Identity Document
</pre>
    <p>I understand the distinction you wish to make here, between an
      acronym and abbreviation, but I think it&#39;s a meaningless
      distinction. In this case, `Id` would be fine for &quot;identifier&qu=
ot;,
      but &quot;Identity Document&quot; should simply be `IdentityDocument`=
.
      Whilst the distinction may seem meaningful to you, it certainly
      does not look that way to me; I think it would be difficult to
      remember and explain to someone else. Perhaps the tie breaker
      could be that it wouldn&#39;t be meaningful to an automated style
      checker, either. That is, it would be difficult to enforce this
      policy exception in any automated way. Why not just keep it simple
      and consistent here, disallowing runs of multiple upper-case
      letters?</p>
    <p>Cheers,<br>
      Bilge<br></p></div></blockquote><div>I was under the impression that =
this RFC was trying to solve exactly that, so I&#39;m surprised=C2=A0to see=
 that ID would be allowed.<br></div></div></div>

--000000000000a3dc96061677d2fb--