Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123157
Content-Type: multipart/alternative;
 boundary="------------JaAsf5xwbusqZ34CPOFl9hLz"
Message-ID: <08200b2f-55ca-4e8f-aeb3-d5b07bf3ae3c@scriptfusion.com>
Date: Fri, 19 Apr 2024 19:47:43 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names
To: internals@lists.php.net
References: <792b2282-b7a3-40dd-899c-daab55353316@bastelstu.be>
 <f7efdf8c-826f-460e-80c0-53f4ca27e8cb@bastelstu.be>
Content-Language: en-GB
In-Reply-To: <f7efdf8c-826f-460e-80c0-53f4ca27e8cb@bastelstu.be>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------JaAsf5xwbusqZ34CPOFl9hLz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 19/04/2024 18:42, Tim Düsterhus 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üsterhus

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 
and abbreviation, but I think it's a meaningless distinction. In this 
case, `Id` would be fine for "identifier", but "Identity Document" 
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'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

--------------JaAsf5xwbusqZ34CPOFl9hLz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 19/04/2024 18:42, Tim Düsterhus
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f7efdf8c-826f-460e-80c0-53f4ca27e8cb@bastelstu.be">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.
      <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üsterhus
      <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 class="code">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's a meaningless
      distinction. In this case, `Id` would be fine for "identifier",
      but "Identity Document" 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'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>
    <p></p>
  </body>
</html>

--------------JaAsf5xwbusqZ34CPOFl9hLz--