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
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