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
