Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121058
To: internals@lists.php.net
References: <01e3ff17-5088-0431-6014-82ef4e4789b2@bastelstu.be>
 <48699eff-c0d1-43de-b68e-2327fa601528@gmail.com>
 <64FE7480.6040505@adviesenzo.nl>
Message-ID: <650217AB.6020405@adviesenzo.nl>
Date: Wed, 13 Sep 2023 22:12:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <64FE7480.6040505@adviesenzo.nl>
Content-Type: multipart/alternative;
 boundary="------------050702020905020908050101"
Subject: Re: [PHP-DEV] Casing of acronyms in class and method names
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------050702020905020908050101
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 13-9-2023 17:48, Ben Ramsey wrote:
> On 9/10/23 20:59, Juliette Reinders Folmer wrote:
>> With the above in mind, I wonder how much confusion/code churn 
>> renaming existing classes will cause and if that's worth it, 
>> especially as the suggested case for the PHP native class will likely 
>> be determined by the version on which the tooling is being run. I.e. 
>> tool being run on PHP 8.2 suggest DOMDocument, tool being run on PHP 
>> 8.4 would flag DOMDocument and suggest DomDocument...
>
>
> Since the names are case-insensitive, if the tools continue to 
> enforce, for example, DOMDocument instead of DomDocument, would that 
> cause problems if Reflection, var_dump, etc. began reporting the class 
> name as DomDocument?
>
> In other words, if the tools did not change, would there be any churn?

Tools wouldn't need to change to change their messaging on this.

In my experience, the case of the class as defined by PHP would be 
retrieved from PHP itself, so without the tooling changing, if PHP 
changes the case, the tooling will demand the new casing of the class 
names if run on a PHP version using the new casing. (and the old casing 
when run on an older PHP version)

Might be clearer via the below pseudo-code of typical logic used in 
tooling for checks like this:

$declared_classes = [];
if (empty($declared_classes)) {
     $declared_classes = get_declared_classes();
     $declared_classes = array_combine($declared_classes, 
$declared_classes);
     $declared_classes = array_change_key_case($declared_classes, 
CASE_LOWER);
}

....

$seenClassLc = strtolower($seenClass);
if (isset($declared_classes[$seenClassLc]) && $seenClass !== 
$declared_classes[$seenClassLc]) {
     // Throw error about the incorrect case being used.
}

Hope this clarifies my earlier comment.


And yes, I suspect changing the case will cause issues when name based 
comparisons are done in code as while tooling will use code like the 
above, in application code, names are often not compared in a 
case-insensitive manner.

Smile,
Juliette

--------------050702020905020908050101--