Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122977
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>
 <69107662-eb03-4b75-8eed-59dd2eed6559@gmail.com>
Message-ID: <66103C7A.3040906@adviesenzo.nl>
Date: Fri, 5 Apr 2024 20:01:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <69107662-eb03-4b75-8eed-59dd2eed6559@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------010104060007040509050609"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------010104060007040509050609
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5-4-2024 19:48, Niels Dossche wrote:
> On 05/04/2024 19:00, Tim Düsterhus wrote:
>> I've just written up the follow-up RFC to my previous “Casing of acronyms in class and method names” thread and I'm officially opening up the discussion period for it.
>>
>> Please find the following links for your convenience:
>>
>> RFC: https://wiki.php.net/rfc/class-naming-acronyms
>> Previous ML discussion: https://externals.io/message/120959#120959
>> Related discussion in PHP-FIG: https://github.com/php-fig/per-coding-style/issues/83

Tim,

In the "It decreases readability" section you make a sweeping statement 
about accessibility, but don't back that up with research. Please back 
your statement up as based on my understanding, the opposite is true.

Case in point: if written in all caps, screenreaders will spell the 
characters out - think HTML -. If written in Mixed case, screenreaders 
will try to pronounce the word, making acronyms and other abbreviations 
very hard to understand for anyone using a screenreader.

This is something which has repeatedly been pointed out, for instance at 
conferences regarding conference acronym hashtags, like #DPC.

So, I'd be very interested to see your statement backed up by actual 
research and invite you to look into this a little deeper.


>> I support this proposal.
>> If accepted, I'll make the necessary changes to ext-dom and ext-xsl to comply with the new policy.
Niels: just wondering what changes you are referring to ? The RFC 
explicitly states "Existing class and method names in released versions 
are not affected"... ?


Smile,
Juliette

--------------010104060007040509050609
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 5-4-2024 19:48, Niels Dossche wrote:<br>
    </div>
    <blockquote
      cite="mid:69107662-eb03-4b75-8eed-59dd2eed6559@gmail.com"
      type="cite">
      <pre wrap="">On 05/04/2024 19:00, Tim Düsterhus wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">I've just written up the follow-up RFC to my previous “Casing of acronyms in class and method names” thread and I'm officially opening up the discussion period for it.

Please find the following links for your convenience:

RFC: <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/class-naming-acronyms">https://wiki.php.net/rfc/class-naming-acronyms</a>
Previous ML discussion: <a class="moz-txt-link-freetext" href="https://externals.io/message/120959#120959">https://externals.io/message/120959#120959</a>
Related discussion in PHP-FIG: <a class="moz-txt-link-freetext" href="https://github.com/php-fig/per-coding-style/issues/83">https://github.com/php-fig/per-coding-style/issues/83</a>
</pre>
      </blockquote>
    </blockquote>
    <br>
    Tim,<br>
    <br>
    In the "It decreases readability" section you make a sweeping
    statement about accessibility, but don't back that up with research.
    Please back your statement up as based on my understanding, the
    opposite is true.<br>
    <br>
    Case in point: if written in all caps, screenreaders will spell the
    characters out - think HTML -. If written in Mixed case,
    screenreaders will try to pronounce the word, making acronyms and
    other abbreviations very hard to understand for anyone using a
    screenreader.<br>
    <br>
    This is something which has repeatedly been pointed out, for
    instance at conferences regarding conference acronym hashtags, like
    #DPC.<br>
    <br>
    So, I'd be very interested to see your statement backed up by actual
    research and invite you to look into this a little deeper.<br>
    <br>
    <br>
    <blockquote
      cite="mid:69107662-eb03-4b75-8eed-59dd2eed6559@gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">I support this proposal.
If accepted, I'll make the necessary changes to ext-dom and ext-xsl to comply with the new policy.
</pre>
      </blockquote>
    </blockquote>
    Niels: just wondering what changes you are referring to ? The RFC
    explicitly states "Existing class and method names in released
    versions are not affected"... ?<br>
    <br>
    <br>
    Smile,<br>
    Juliette<br>
  </body>
</html>

--------------010104060007040509050609--