On 11-9-2023 1:57, Ben Ramsey wrote:
I agree. Using uppercase for the first letter in an acronym and
lowercase for subsequent letters appears to be prevalent in many
userland libraries, so it seems to be what users expect.
Since class names in PHP aren't case-sensitive, there should be no BC
concerns for changing existing classes to fit this new casing (for
Reflection, debug, and documentation purposes). That is, if we wanted
to also update all existing class names in PHP that contain acronyms
(e.g., DOMDocument -> DomDocument, SimpleXMLElement ->
SimpleXmlElement, etc.).
This prevalence may stem from various CS checks enforcing/suggesting the
naming like that based on their implementation/interpretation of
CamelCaps name checks, often related to PSR4.
Along the same lines, I'm aware of CS-like tools enforcing the use of
PHP native class names to be in the case as defined in PHP (mostly to
prevent confusion when people search for more info on the class and
such, even though it doesn't matter for the actual use).
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...
Smile,
Juliette
