Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed all
affected language features and functionalities.
I still need to perform the impact analysis and the performance benchmarks.
I will add them to the RFC and inform in the thread when I complete it.
RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed all
affected language features and functionalities.I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
Hi Jorg,
I am in favor of this RFC. Case sensitivity in PHP is particularly
challenging from a static analysis perspective, as it currently requires us
to perform normalization and maintain tracking for both normalized and
original names for error reporting. It is also an issue for Zend itself,
and I see little benefit in maintaining it when the majority of languages
listed in the RFC do not. Existing codebases could resolve these issues
using migration tools, and a deprecation period until 9.0 is a good
approach.
However, I would like some clarification regarding the plan for 9.0 to
"Promote deprecations to E_ERROR." This could be interpreted in two ways:
- Replacing
E_DEPRECATEDwithE_ERROReverywhere, which I believe would
be incorrect. - Removing the deprecation and tolower in the engine so that a case
mismatch results in an error as if the symbol does not exist. This seems
like the correct path, but describing it as "promoting deprecations to
E_ERROR" might be misleading. For example, a call like is_a($foo, 'FOO');
that previously emittedE_DEPRECATEDand returned true would now return
false.
Cheers,
Seifeddine Gmati
I would be fully in favour of this RFC, but there is 1 hurdle which cant be
ignored.
What should the PHP naming convention be for these?
Without deciding on what it should be we would be creating a new issue of
mix-mash of uppercase, lowercase and camelcase classes for example
Few examples
- DateTime is documented as Camelcase -
https://www.php.net/manual/en/class.datetime.php - PDO is documented as uppercase -
https://www.php.net/manual/en/class.pdo.php - mysqli is documentated as lowercase -
https://www.php.net/manual/en/set.mysqlinfo.php - ArrayAccess is documented as camelcase -
https://www.php.net/manual/en/class.arrayaccess.php
PHP mixing case of definitions, at least with current system, users can
choose their preferred convention and it will work.
If we change to be case sensitive, we risk introducing a giant headache for
devs, as they need to remember what different casing each different builtin
class is.
It will become a the new ($haystack, $needle) - ($needle, $haystack)
problem, and won't gain love from the community.
Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed all
affected language features and functionalities.I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
I would be fully in favour of this RFC, but there is 1 hurdle which cant
be ignored.What should the PHP naming convention be for these?
Without deciding on what it should be we would be creating a new issue
of mix-mash of uppercase, lowercase and camelcase classes for exampleFew examples
- DateTime is documented as Camelcase - https://www.php.net/manual/en/
class.datetime.php https://www.php.net/manual/en/class.datetime.php- PDO is documented as uppercase - https://www.php.net/manual/en/
class.pdo.php https://www.php.net/manual/en/class.pdo.php- mysqli is documentated as lowercase - https://www.php.net/manual/en/
set.mysqlinfo.php https://www.php.net/manual/en/set.mysqlinfo.php- ArrayAccess is documented as camelcase - https://www.php.net/manual/
en/class.arrayaccess.php <https://www.php.net/manual/en/
class.arrayaccess.php>PHP mixing case of definitions, at least with current system, users can
choose their preferred convention and it will work.
If we change to be case sensitive, we risk introducing a giant headache
for devs, as they need to remember what different casing each different
builtin class is.
It will become a the new($haystack, $needle)-($needle, $haystack)
problem, and won't gain love from the community.
There are already policies for that:
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst
As for the existing stuff that you mention, we already have this casing
salad anyway even if we simply follow IDE autocomplete
--
Anton
As for the existing stuff that you mention, we already have this casing
salad anyway even if we simply follow IDE autocomplete
Yes we do, hence why I would love for this RFC to pass and the standard
library be unified by the standards you linked.
However, unless compromise is made to do so this RFC would cause more
problems than it solves.
I think this is really down to a case where PHP has held onto too much
legacy problems, and attempts to fix those problems cause more problems.
For userland definitions I think this can be adapted quickly to that
subsection, because ideally developers should be following the
documentation.
It doesn't break PHP, it breaks incorrect implementations of userland
code and helps enforce good developer behaviour, such as following the
definition
Eg, if the developer defines \Movies\ILike\Moneyball and then the
implementer uses \movies\ilike\MoneyBall` then I can agree, that should
generate an error
Implementations like this: https://3v4l.org/FQKLq I 100% agree, should not
be possible.
But for internal PHP definitions I'm not sure what a solution would be
which does not completely havoc.
I would be fully in favour of this RFC, but there is 1 hurdle which cant be ignored.
What should the PHP naming convention be for these?
Without deciding on what it should be we would be creating a new issue of mix-mash of uppercase, lowercase and camelcase classes for example
Few examples
- DateTime is documented as Camelcase - https://www.php.net/manual/en/class.datetime.php
- PDO is documented as uppercase - https://www.php.net/manual/en/class.pdo.php
- mysqli is documentated as lowercase - https://www.php.net/manual/en/set.mysqlinfo.php
- ArrayAccess is documented as camelcase - https://www.php.net/manual/en/class.arrayaccess.php
PHP mixing case of definitions, at least with current system, users can choose their preferred convention and it will work.
If we change to be case sensitive, we risk introducing a giant headache for devs, as they need to remember what different casing each different builtin class is.
It will become a the new($haystack, $needle)-($needle, $haystack)problem, and won't gain love from the community.Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I have collected the points raised in previous discussions, and browsed all affected language features and functionalities.
I still need to perform the impact analysis and the performance benchmarks. I will add them to the RFC and inform in the thread when I complete it.RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
I honestly can’t think of anything good that this RFC would bring. It would bring this cased salad into every code base and require changing code if you use a consistent casing throughout your code base. Just so that person and Person are different? That just sounds confusing to me.
I’m not sure the gain — which I’m also unsure what the gain even is — is worth it.
— Rob
I would be fully in favour of this RFC, but there is 1 hurdle which cant
be ignored.What should the PHP naming convention be for these?
I absolutely can ignore that.
While consistency is nice, it is not valuable by itself.
Most people who are still writing code by hand, use IDEs with autocomplete.
And I doubt LLMs care.
Just leaving whatever TyPoGraphy that is currently in the source code, and
ignoring any inconsistency is almost certainly the correct choice.
cheers
Dan
Ack
Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed
all affected language features and functionalities.I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
Hey,
- I don't think it's necessary to mess with ::class here.
People are used to it not doing any checks. If it started doing some
checks it would
get confusing: why does it tell me if the case is wrong but says nothing
if the class
doesn't exist? And the warning is fired conditionally on whether the
class is already
loaded or not, which, according to RFC, is not a cool behaviour.
Besides that wrong case warning would disappear and go back to silent
in PHP 9.0, right?
- Is the end goal in PHP 9.0 such that ActivityLog and Activitylog
could both be defined
as separate classes? And I can define my own StdClass? Or would
definitions that only
differ by case still be separate?
BR,
Juris
1. I don't think it's necessary to mess with ::class here.
People are used to it not doing any checks. If it started doing some
checks it would
get confusing: why does it tell me if the case is wrong but says nothing
if the class
doesn't exist? And the warning is fired conditionally on whether the
class is already
loaded or not, which, according to RFC, is not a cool behaviour.Besides that wrong case warning would disappear and go back to silent
in PHP 9.0, right?
I agree, that #2.9.2 is basically a string constant not really related
to the class itself, adding a check is not beneficial. If that string is
used to initiate a class, there will be some another warning from this
RFC about it anyway.
--
Anton
Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I
have collected the points raised in previous discussions, and browsed
all affected language features and functionalities.I still need to perform the impact analysis and the performance
benchmarks. I will add them to the RFC and inform in the thread when I
complete it.RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
Is there a practical, real-world issue this solves? I have never in my life seen someone write STRLEN(). Drupal used to use TRUE/FALSE instead of true/false, but I don't know if they've ever changed that and it doesn't hurt anything. Class names everyone should already be treating as case sensitive because of the file system. And IDEs and SA tools have been pushing toward the "standard" casing of things for decades. I don't really see this as an issue to solve.
But I can see where it could cause issues when making dynamic method calls, like $controller->$httpMethod($request), which is something a number of smaller frameworks have done for years.
So I'm -1 at this point.
--Larry Garfield
Is there a practical, real-world issue this solves? I have never in my life seen someone write
STRLEN(). Drupal used to use TRUE/FALSE instead of true/false, but I don't know if they've ever changed that and it doesn't hurt anything. Class names everyone should already be treating as case sensitive because of the file system. And IDEs and SA tools have been pushing toward the "standard" casing of things for decades. I don't really see this as an issue to solve.
I think end users see no problem being solved here. And that's okay.
However, this change helps the engine (and any tool that deals with
PHP symbol definitions, analyzers, LSPs, etc.) by making symbol
management easier, as it removes the need for a folding pass required
on every identifier encountered.
This also helps make PHP more consistent, first, with other
programming languages, and secondly, with itself, since constants in
PHP are already case-sensitive, so making everything behave the same
is a win.
And as you said, no one writes STRLEN, and people write code
assuming that the casing they are using is correct per definition, not
for style reasons. The deprecation phase would help people spot
incorrect casings in their application for now, until the 9.0 upgrade.
Cheers,
Seifeddine.
Thanks for all opinions. I will apply all changes in coming days to the RFC
content.
Is there a practical, real-world issue this solves?
Portability of the autoloading. I had a case in the past where my wrongly
cased namespace didn't cause any problem locally, but it failed in the
production because of different OS. This is real world-issue.
However, this problem touches only namespaces and class names. If the RFC
would be only for namespaces and classes would you be in favor of this RFC?
It appeared in previous discussions to put all or nothing into such RFC, so
I went along the lines, but I'm okay with dropping methods and functions.
However, if RFC function autoloading would pass, we would have the same
problem with functions.
Kind regards,
Jorg
Thanks for all opinions. I will apply all changes in coming days to the
RFC
content.Is there a practical, real-world issue this solves?
Portability of the autoloading. I had a case in the past where my
wrongly
cased namespace didn't cause any problem locally, but it failed in the
production because of different OS. This is real world-issue.
Well, not in PHP AFAIK.
SPL class autoloading was designed under portability
principles and properly vetted in this regard, from top
of my head since it's incarnation in PHP 5.1.
So I'd be highly interested where PHP's standard class
autoloading has this "real world-issue" in its collation.
E.g. did you use a specific PHP script to generate the
dynamic include instructions?
Or were those templated by some specific PHP script, or
were you implementing or inheriting a specific framework
that makes use of PHP scripts etc. that undermined
standard stability and portability principles in software
and system design?
More context warmheartly appreceated.
Best,
--hakre
E.g. did you use a specific PHP script to generate the
dynamic include instructions?
Yes, I used composer packager.
I'm sorry, but I'm going to stop work on this RFC. I see very little chance
it passing,
so I want to spend time more efficiently. I spent already a lot of time on
it, and if anyone
wants to continue it, feel free to do it. I hope you understand.
Kind regards,
Jorg
Is there a practical, real-world issue this solves? I have never in my life seen someone write
STRLEN().
I've seen quite a few casing mismatches in practice, intentionally
added for readability, especially in calls to GD functions.
ImageColorAllocateAlpha() does read better than
imagecolorallocatealpha().
--
Best regards,
Bruce Weirdan mailto:weirdan@gmail.com
I've seen quite a few casing mismatches in practice, intentionally
added for readability, especially in calls to GD functions.
ImageColorAllocateAlpha()does read better than
imagecolorallocatealpha()
I would love to see normalizing function and class name casing (functions
in camelCase, classes in PascalCase) happen at the same time as case
sensitivity.
If we are forcing devs to search and replace in their codebases, it would
make sense to get the most value we can out of it.
I think this is a good idea, however I think some care needs to be
taken so that it doesn't impose a significant burden on end users
compared to the benefit returned.
In respect to the exact detail:
- 2.9: As already noted by Juris, I also disagree with changing
::classresolution to have magic behaviour based on if the class
exists or not (at the time of the usage) - I would prefer keeping that
as a static transformation and raising the deprecation if the string
is used. - 2.37: The example is a little unclear; could the example be updated
to include the actual class instantiation / function call; and confirm
if the error message references the line of the call site / the line
of the use statement / both? Further to this, just to confirm it is
correct; there is no difference in the error message when a use
statement is/isn't present? - 2:37: When I read 'The as alias itself is not checked: use
MyApp\Service\UserService as US is fine regardless of what US is. Only
the namespace path being imported is validated.' then I interpreted
that as it would mean that in the code the developer could donew us();- is that correct? If not, it might be worth just reviewing the
wording. - 2.39 / 2.40: I don't agree with this in the initial version - it
makes sense to do but I would prefer this as a future change.
Initially I would suggest that unserialize continues to work without a
deprecation / error - the update that a developer would need to do in
response to the deprecation occurring (for data still serialized)
would either be having a script that unserializes and then
reserializes the data just to correct the case, manual editing the
data, or ignoring/suppression the deprecation; none of which seem
particularly useful against the harm by having a special case when
unserialzing data. (Note this relies on prohibiting multiple items
with the same name but different case for a period from my general
feedback) - 2.41: My SOAP knowledge is a bit rusty; but from memory then naming
on the SOAP side are case sensitive; but if I am incorrect here then I
would not enforce case sensitivity on the PHP side either (as the
types could change on the server side with no ill effect)
General:
- What change is there to the default implementation for
__autoload
(https://www.php.net/manual/en/function.spl-autoload.php)? Currently
this will load class names with any case as long as the PHP files are
lowercase in the file system (or a case insensitive file system is
used). - Would a function that can normalize the case of items currently case
insensitive be useful to introduce alongside this (where the item
exists in the symbol tables of course)? My thoughts are for
compatibility with code you don't control - if a third party library
intends to change their internal casing following this change; a
developer may want to be able to use a proxy for accessing their
resources that allows the old casing to work without raising the
deprecations (or errors in PHP9) once the update is released without
needing to immediate update the first party code. (This could be done
in userland, but I would expect it would be more efficient to do in
the engine) - For some internal classes/functions which don't follow the expected
rules, should aliases be introduced (or the deprecations suppressed
during the deprecation stage). Although I rarely use it myself, I only
realised when reviewing this RFC that 'stdClass' is not 'StdClass' for
instance. - I would suggest that for PHP9.0 then having multiple items (or at a
minimum then autoloadable items) with the same name but with different
casing is prohibited. I would be concerned of much harder to detect
issues if PHP8.6 introduces the deprecation and then PHP9.0 (assuming
that was the next release after 8.6) then removed the deprecation and
allowed you to define the classes 'Foo' and 'foo' that a significant
number of users would upgrade from PHP8.5 to PHP9.0 and manage to end
up with different items that they expect are the same. I wouldn't have
an issue allowing it in PHP10; or given the motivations given so far
for the change keeping this prohibted.
Robert
Hello internals,
I would like to revive the discussion about fully case-sensitive PHP. I have collected the points raised in previous discussions, and browsed all affected language features and functionalities.I still need to perform the impact analysis and the performance benchmarks. I will add them to the RFC and inform in the thread when I complete it.
RFC: https://wiki.php.net/rfc/case_sensitive_php
Kind regards,
Jorg
Hi Jorg,
thank you for the RFC, and for taking the time to identify a whole list of
things that should be looked at for normalising. It looks like a useful
reference.
Array keys “key” != “Key”
This is objectively terrible behaviour.
But changing it would break so much code, in such subtle ways that I don't
think it would be acceptable for the current distribution to change.
The current distribution is also somewhat terrible.
Not even through bad design, just through choices made in an era where
software was still often shipped on disk, and compiling PHP took overnight.
So you get things happen such, as setting the "C" locale to France results
with invalid SVG files being generated.
I think it's probably worth discussing a new distribution, which would be
an opportunity for cleanups like this.
I also think that PHP is not a good "my first programming language". I find
it hard to imagine newbies pushing through the difficult bit of getting
started, to build something cool to show their friends.
cheers
Dan
Ack