Hi,
I don't know if this was discussed before. So, tell me what you think before
I write an RFC.
I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
Regards
Francois
Hi Francois,
It's too big of a BC change firstly.
Secondly it has no language benefit or developer benefit.
The only benefit is case correctness which is a nice to have. Making sure
existing code works is a must have.
Cheers,
Paul
Hi,
I don't know if this was discussed before. So, tell me what you think
before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.Regards
Francois
It's too big of a BC change firstly.
Secondly it has no language benefit or developer benefit.
Are you sure? Autoloading schemes such as PSR-4 derive pathnames from
class names without converting them to lowercase. If case mismatches go
undetected and unreported, a project might work on a developer's Windows
desktop (case-insensitive) yet not when uploaded to a Linux web server
(case-sensitive). Or when an object instantiation or a static method
call using the correct case is removed from the code, a later call using
the incorrect case might break.
Backward compatibility is perhaps a good reason to not make this change.
However, I would like to see at least an option to report case
mismatches in class names as E_STRICT errors and possibly a way to
disable that for specific files or classes when necessary.
I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
It's too big of a BC change firstly.
Secondly it has no language benefit or developer benefit.
Are you sure? Autoloading schemes such as PSR-4 derive pathnames from
class names without converting them to lowercase. If case mismatches go
undetected and unreported, a project might work on a developer's Windows
desktop (case-insensitive) yet not when uploaded to a Linux web server
(case-sensitive). Or when an object instantiation or a static method
call using the correct case is removed from the code, a later call using
the incorrect case might break.Backward compatibility is perhaps a good reason to not make this change.
However, I would like to see at least an option to report case
mismatches in class names asE_STRICTerrors and possibly a way to
disable that for specific files or classes when necessary.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.--
+1 on E_STRICT warning for case mismatch on class names. Also +1 on eventual case sensitivity for userland class names. Not convinced the rest is worth it.
The insensitivity makes code brittle. Sometimes the same code will run fine, and other times it breaks depending on what lines triggered the auto loader. If you instantiate a Foo instance first, then instantiate a new foo, the code runs fine, but if you try to instantiate a new foo first, we get a fatal error.
Cheers,
David
Hey,
The insensitivity makes code brittle. Sometimes the same code will run fine, and other times it breaks depending on what lines triggered the auto loader. If you instantiate a Foo instance first, then instantiate a new foo, the code runs fine, but if you try to instantiate a new foo first, we get a fatal error.
I’d say that’s not the fault of insensitivity, but the fault of poorly-written autoloaders.
Thanks.
Andrea Faulds
http://ajf.me/
Hey,
The insensitivity makes code brittle. Sometimes the same code will run
fine, and other times it breaks depending on what lines triggered the auto
loader. If you instantiate a Foo instance first, then instantiate a new
foo, the code runs fine, but if you try to instantiate a new foo first, we
get a fatal error.I’d say that’s not the fault of insensitivity, but the fault of
poorly-written autoloaders.
I'd like to know if there's an autoloader that handles case sensitivity
without O(2^n) stat calls worst-case scenario (N being namespace/class name
parts chars).
A stricts standards warning in case of type sensitivity issues after a
class with the same was already loaded would make a lot of sense:
class Foo {}
$foo = new Foo;
$bar = ($foo instanceof foo); // stricts standards
Same goes for type-hints in methods, as those may break reflection (which
triggers autoloading).
Greets,
Marco Pivetta
Hey,
The insensitivity makes code brittle. Sometimes the same code will run
fine, and other times it breaks depending on what lines triggered the auto
loader. If you instantiate a Foo instance first, then instantiate a new
foo, the code runs fine, but if you try to instantiate a new foo first, we
get a fatal error.I’d say that’s not the fault of insensitivity, but the fault of
poorly-written autoloaders.I'd like to know if there's an autoloader that handles case sensitivity
without O(2^n) stat calls worst-case scenario (N being namespace/class name
parts chars).
Yes. Those running on Windows or OS X (both use case-insensitive filesystems by default), those that convert the class name to lowercase, those that error on non-lowercase class names, etc.
--
Andrea Faulds
http://ajf.me/
Hey,
The insensitivity makes code brittle. Sometimes the same code will run
fine, and other times it breaks depending on what lines triggered the
auto
loader. If you instantiate a Foo instance first, then instantiate a new
foo, the code runs fine, but if you try to instantiate a new foo first,
we
get a fatal error.I’d say that’s not the fault of insensitivity, but the fault of
poorly-written autoloaders.I'd like to know if there's an autoloader that handles case sensitivity
without O(2^n) stat calls worst-case scenario (N being namespace/class
name
parts chars).Yes. Those running on Windows or OS X (both use case-insensitive
filesystems by default),
Except that nobody I know of runs production on a case-insensitive
filesystem.
those that convert the class name to lowercase, those that error on
non-lowercase class names, etc.
That's an interesting idea to be honest: could be brought up in the
composer mailing list, I'd say.
Marco Pivetta
Except that nobody I know of runs production on a case-insensitive
filesystem.
I know a lot, really a lot.
Except that nobody I know of runs production on a case-insensitive
filesystem.I know a lot, really a lot.
Yeah, I think it’s too easy to forget that not everyone’s using something Unix-like… a lot of people use Windows Server!
--
Andrea Faulds
http://ajf.me/
Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems.
Mike Dugan
Sent from my iPhone
Except that nobody I know of runs production on a case-insensitive
filesystem.I know a lot, really a lot.
Yeah, I think it’s too easy to forget that not everyone’s using something Unix-like… a lot of people use Windows Server!
--
Andrea Faulds
http://ajf.me/
Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems.
I think we coul be more realistic here.
In my opinion the pains introduced by such a change does not match
with any possible gains. Many areas affect the request time badly
(IOs, mem, etc), I do not see case insensitivity as one, even if it
may look very bad if a simple small script is taken as example of the
slowdown (obviously worst case).
I am not saying discussing that is bad, but it may not be the most
important thing to spend time on :)
Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems.
I think we coul be more realistic here.
In my opinion the pains introduced by such a change does not match
with any possible gains. Many areas affect the request time badly
(IOs, mem, etc), I do not see case insensitivity as one, even if it
may look very bad if a simple small script is taken as example of the
slowdown (obviously worst case).I am not saying discussing that is bad, but it may not be the most
important thing to spend time on :)
Agree..
I am afraid that will never happen(case-sesentive class/function name)
in the whole php life
thanks
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
If the core functionality remains ASCII based then there is no need to drop case insensitivity, but if there is a move to better multi-lingual support, then it may be necessary for compatibility with Unicode?
Sent from my android device so the quoting is crap!
-----Original Message-----
From: Xinchen Hui laruence@php.net
To: Pierre Joye pierre.php@gmail.com
Cc: Mike Dugan mike@mjdugan.com, Andrea Faulds ajf@ajf.me, Marco Pivetta ocramius@gmail.com, PHP internals internals@lists.php.net, David Muir davidkmuir@gmail.com, Paul Dragoonis dragoonis@gmail.com, "nf.laupretre@yahoo.fr" nf.laupretre@yahoo.fr, Kevin Israel pleasestand@live.com
Sent: Mon, 22 Dec 2014 6:25 AM
Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Development should also be a consideration, I see a lot of developers using Windows for local development (even on the irc channels). These are the same ones who are, in my experience, less likely to be aware of solutions like Vagrant just as much as the subtleties of case sensitivity across operating systems.
I think we coul be more realistic here.
In my opinion the pains introduced by such a change does not match
with any possible gains. Many areas affect the request time badly
(IOs, mem, etc), I do not see case insensitivity as one, even if it
may look very bad if a simple small script is taken as example of the
slowdown (obviously worst case).I am not saying discussing that is bad, but it may not be the most
important thing to spend time on :)
Agree..
I am afraid that will never happen(case-sesentive class/function name)
in the whole php life
thanks
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
De : Pierre Joye [mailto:pierre.php@gmail.com]
In my opinion the pains introduced by such a change does not match
with any possible gains. Many areas affect the request time badly
(IOs, mem, etc), I do not see case insensitivity as one
Right. It is not a question of performance, as the expected gain is negligible. More important are the side effects caused by case insensitivity, especially the fact that it is not compatible with PSR autoload conventions (ok, on case-sensitive file systems only, but is is still worse to have different behaviors on different environments).
I still think PHP 7 is the occasion to cleanup this issue with minimal pain. If we don't do it now, I am also afraid it will never happen.
I am not saying discussing that is bad, but it may not be the most
important thing to spend time on :)
With all due respect, I don't like the idea that you know better than me what's important or not.
With all due respect, I don't like the idea that you know better than me
what's important or not.
I should put the "I am not saying .." outlined. Also no matter how we look
at it, there are actually a good amount of things that we must solve or
provide in 7, things we do not remotely approach by now. So yes, seeing
this discussion running in circle worries me, a bit.
My point is: there is almost zero chance to see that happen. I do not have
anything against that but BC, keeping in mind the insane amount of ppl I
know who will be affected by that.
Hi all,
+1 on
E_STRICTwarning for case mismatch on class names. Also +1 on
eventual case sensitivity for userland class names. Not convinced the rest
is worth it.The insensitivity makes code brittle. Sometimes the same code will run
fine, and other times it breaks depending on what lines triggered the auto
loader. If you instantiate a Foo instance first, then instantiate a new
foo, the code runs fine, but if you try to instantiate a new foo first, we
get a fatal error.
It seems the most reasonable approach for this issue.
+1
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
I don't know if this was discussed before. So, tell me what you think before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
Variables are also case sensitive.
Identifiers can contain a-zA-Z0-9_ + where top bit is set.
Where an identifier is a function name or class name comparison is in a case
insensitive manner ... but only for ASCII ... using tolower_map in zend_operators.c
This means that those who write function (etc) names in some encoding that is
more than US ASCII find that case comparison is done in a case sensitive manner
- at least for those parts of identifiers that are written in characters that
have the top bit set.
Fixing this would require a lot of work as well as some way of determining what
character encoding the source file was written in ... different includes might
have different encodings.
We recently talked about a way of specifying source file encoding and decided
that it was not something to look at now (IIRC).
Making namespaces, function & classes case sensitive makes PHP consistent to
everyone - not just us 'US ASCII chauvinists' -- it is also the simplest approach.
It is a BC break; one which, unfortunately, cannot be found at compile time.
However: code, when fixed (ie consistent case spelling), will continue to work
with current PHP implementations.
Although many do try to write these identifiers in a case consistent manner it
will cause problems, however I would suggest that it would be worth doing.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
Fixing this would require a lot of work as well as some way of
determining what
character encoding the source file was written in ... different
includes might
have different encodings.We recently talked about a way of specifying source file encoding and
decided
that it was not something to look at now (IIRC).
I haven't read the whole thread yet, so apologies if someone's mentioned this already, but far from being a rejected feature, specifying source file encoding is already possible, using declare(encoding=...)
The problem is what to do with that information: presumably, identifiers would need to be converted to an internal encoding (prob utf8), case folded, and normalised (in the Unicode sense of that term). Ideally, this would happen during compilation and stored appropriately in the OpCache, but a run-time path for userland strings would also be necessary.
Hey François, (I assume there’s a ç, I apologise if not)
I don't know if this was discussed before. So, tell me what you think before
I write an RFC.
Ah, this subject has come up before, I think. :)
I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
I’d thought of doing this before, but the backwards-compatibility cost is too high.
I would like to see more case uniformity, but I think this is the less practical direction. Instead of making everything case-sensitive, we should make everything case-insensitive, which would break far less stuff, and is a smaller change. That’d mean constants, variable names and properties would need changing, everything else is already case-insensitive.
I don’t think making constants and variable names case-insensitive would cause a problem. I reckon it’s unlikely that someone has two constants differing only by case, ditto for variable names, and both live in their own namespaces so this wouldn’t create conflicts. Even if someone does, this is probably quite a rare occurrence and could be easily fixed.
The problematic case is properties, because although PHP code probably doesn’t rely on them being case-sensitive most of the time, lacking preservation of case for serialised properties would be quite a problem. For example, an object serialised to JSON and then decoded might, with the right flags passed, be unserialised as an array. Array keys are case-sensitive in PHP (as they should be, I don’t want to change that), so now a lookup that worked before might not now because the case wasn’t preserved. Even if we took care to preserve case, there’s also the problem of objects used as associative arrays, which we explicitly encourage with ArrayObject. Plus, JSON objects decode to PHP objects by default, so objects used as case-sensitive dictionaries in incoming JSON would break. For these reasons, I don’t think we should touch properties.
In summary, case-sensitivity everywhere would be a massive BC break, but case-insensitivity for everything except properties might be doable.
Thanks for writing! :)
Andrea Faulds
http://ajf.me/
I would like to see more case uniformity, but I think this is the less practical direction. Instead of making everything case-sensitive, we should make everything case-insensitive, which would break far less stuff, and is a smaller change. That’d mean constants, variable names and properties would need changing, everything else is already case-insensitive.
As I said: this is only partly true; true if you are a Brit or a Yank ...
everyone else who has alphabetics that are represented by bytes with the top bit
set sees them as case sensitive in those parts.
It is a BC break, but a very unusual one in that once code is fixed in, say PHP
7, it would continue to work when copies back to a PHP 5 environment.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
Hey Alain,
I would like to see more case uniformity, but I think this is the less practical direction. Instead of making everything case-sensitive, we should make everything case-insensitive, which would break far less stuff, and is a smaller change. That’d mean constants, variable names and properties would need changing, everything else is already case-insensitive.
As I said: this is only partly true; true if you are a Brit or a Yank ...
everyone else who has alphabetics that are represented by bytes with the top bit
set sees them as case sensitive in those parts.
That’s true. Although mixing English and another language in source code isn’t a terribly good idea anyway.
It is a BC break, but a very unusual one in that once code is fixed in, say PHP
7, it would continue to work when copies back to a PHP 5 environment.
This isn’t that unusual among BC breaks, honestly.
Thanks.
Andrea Faulds
http://ajf.me/
De : Andrea Faulds [mailto:ajf@ajf.me]
I’d thought of doing this before, but the backwards-compatibility cost is too
high.
It is a BC break, I agree, but would the impact on PHP community be so high ? I have never seen any PHP code which would rely on function/class names case-insensitivity. I tested this with Automap, a map-based autoloader, modified to work in a case-sensitive manner. I tested most PHP frameworks and libraries and none of them had case mismatches. There are some, probably, but I guess that most, if not all, are undetected typos. Can't we consider such a mismatch as a bug ? That's what any normal programmer would think, IMHO. So, I think that such a BC break on a problematic syntax is acceptable, and would even help clean some PHP code.
What we can do to minimize the BC break, in the spirit of the migration path discussed these last days, is to introduce an E_STRICT warning in version 5.7, which would help programmers prepare their code for PHP 7.
Regards
François
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F & N Laupretre nf.laupretre@yahoo.fr
wrote:
I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
Defining
thisismyfunction() {}
then call it
THISisMYFunction()
is not recommended at all. Keeping not recommended spec forever is not
a good idea. IMHO. Using strtolower() all over place in the Engine to keep
running not recommended code does not make much sense.
It's BC, but it would be easy spot it by an compatibility check script. Once
case is used properly, scripts run both new and old PHP. Therefore,
BC issue is not critical.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
is not recommended at all. Keeping not recommended spec forever is not
a good idea. IMHO. Usingstrtolower()all over place in the Engine to keep
There's a huge difference between "not recommended" and breaking the
code. Using if() without braces, or inconsistent indentation - is not
recommended. Making such code not work would be a huge mistake.
It's BC, but it would be easy spot it by an compatibility check script. Once
case is used properly, scripts run both new and old PHP. Therefore,
BC issue is not critical.
There's no "therefore" - you'll still have to fix all that code, and if
you think it all will be findable by a simple script, you severely
underestimate the dynamic nature of things people do with PHP. This is a
very big change and should not be dismissed lightly.
--
Stas Malyshev
smalyshev@gmail.com
Hi,
I don't know if this was discussed before. So, tell me what you think before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
I have hard time to see the benefits of breaking so many codes for that.
Userland codes use to rely on case sensitivity naming, based on coding
standard. But for internals names, it is going to be a major pain.
Cheers,
Pierre
I have hard time to see the benefits of breaking so many codes for that.
Has anyone done any benchmarking on the overhead of the internal/hidden convert
to lower case of function/... names ?
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre nf.laupretre@yahoo.fr
wrote:
Hi,
I don't know if this was discussed before. So, tell me what you think
before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
I think that the cost of that BC break is too high, and will only happen in
an alternative implementation (if at all).
Putting that aside, if we want to go down that road, we should first
discourage people from such usage, and as we never did that(no E_STRICT no
E_DEPRECATED) it would be extremely rude to remove support for that in 7.0.
I think that a Pull Request for adding E_STRICT or maybe even E_DEPRECATED
would have a chance of getting voted in but depends on the implementation
and how much overhead would it cost.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
+1 for adding E_DEPRECATED and removing support in PHP 8.
On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre nf.laupretre@yahoo.fr
wrote:Hi,
I don't know if this was discussed before. So, tell me what you think
before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.I think that the cost of that BC break is too high, and will only happen in
an alternative implementation (if at all).
Putting that aside, if we want to go down that road, we should first
discourage people from such usage, and as we never did that(noE_STRICTno
E_DEPRECATED) it would be extremely rude to remove support for that in 7.0.
I think that a Pull Request for addingE_STRICTor maybe evenE_DEPRECATED
would have a chance of getting voted in but depends on the implementation
and how much overhead would it cost.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
+1 for adding
E_DEPRECATEDand removing support in PHP 8.
+1
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre nf.laupretre@yahoo.fr
wrote:Hi,
I don't know if this was discussed before. So, tell me what you think
before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.I think that the cost of that BC break is too high, and will only happen in
an alternative implementation (if at all).
Putting that aside, if we want to go down that road, we should first
discourage people from such usage, and as we never did that(noE_STRICTno
E_DEPRECATED) it would be extremely rude to remove support for that in 7.0.
I think that a Pull Request for addingE_STRICTor maybe evenE_DEPRECATED
would have a chance of getting voted in but depends on the implementation
and how much overhead would it cost.
I cannot agree on even adding a flag here. There is no gain, the code
base won't change but the cost of the notice/deprecation will be too
high as well, relatively speaking.
CS can be used and enforced on a per project basis if a project wants
to rely on the same cases for his application, libs or modules.
Platforms with case insensitive file systems will work just fine.
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC. He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being requested (ie. possible
on windows using meta info), or keep everything the way it is now?
These are all things we should take into account, not only "heh, let
make symbols case sensitive".
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Even if i'm a php developer since a while, i never new or see usage of the
case-insensitive "feature". IMO that's something a bit terrible and people
do not use it but make mistakes that PHP "automatically fix". This
behavior is very weird and comes with bad code quality.
Of course this is a BCBreak, but as Yasuo Ohgaki said, this bc break is not
so hard to detect. Please consider adding the warning in PHP 5.7 and fixing
it in PHP 7.
Thanks for reading.
Cheers,
2014-12-23 8:47 GMT+01:00 Pierre Joye pierre.php@gmail.com:
On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre <nf.laupretre@yahoo.fr
wrote:
Hi,
I don't know if this was discussed before. So, tell me what you think
before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain
is
negligible, I think it could be the right time to question this.I think that the cost of that BC break is too high, and will only happen
in
an alternative implementation (if at all).
Putting that aside, if we want to go down that road, we should first
discourage people from such usage, and as we never did that(noE_STRICT
no
E_DEPRECATED) it would be extremely rude to remove support for that in
7.0.
I think that a Pull Request for addingE_STRICTor maybe even
E_DEPRECATED
would have a chance of getting voted in but depends on the implementation
and how much overhead would it cost.I cannot agree on even adding a flag here. There is no gain, the code
base won't change but the cost of the notice/deprecation will be too
high as well, relatively speaking.CS can be used and enforced on a per project basis if a project wants
to rely on the same cases for his application, libs or modules.
Platforms with case insensitive file systems will work just fine.Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC. He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being requested (ie. possible
on windows using meta info), or keep everything the way it is now?
These are all things we should take into account, not only "heh, let
make symbols case sensitive".Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Even if i'm a php developer since a while, i never new or see usage of the
case-insensitive "feature". IMO that's something a bit terrible and people
do not use it but make mistakes that PHP "automatically fix". This behavior
is very weird and comes with bad code quality.Of course this is a BCBreak, but as Yasuo Ohgaki said, this bc break is not
so hard to detect. Please consider adding the warning in PHP 5.7 and fixing
it in PHP 7.
I have to be clear on my thoughts here:
There is nothing to fix. It is a taste matter, or CS matter. Not a
bug, by no mean.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
De : Pierre Joye [mailto:pierre.php@gmail.com]
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC. He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being requested (ie. possible
on windows using meta info), or keep everything the way it is now?
These are all things we should take into account, not only "heh, let
make symbols case sensitive".
What do you mean with 'case insensitive file ops' ? It's probably clear for most of you but, unfortunately, not for me.
As I'm planning an RFC on case-mismatch deprecation, I'd like to follow your suggestion and include this topic as well.
De : Pierre Joye [mailto:pierre.php@gmail.com]
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC.
For those interested, I just created a PR to raise an E_STRICT message on class and function/method case mismatch :
https://github.com/php/php-src/pull/965
It is not complete yet, as some cases are not trapped, especially for functions, and the corresponding tests are missing. I'll try to write the RFC (to propose the feature for PHP7) and finish the patch this week. Checking constants is more complex than expected as the namespace part is converted to lowercase during the compile phase. This RFC will deal with classes and functions (including class methods) only.
He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being requested (ie. possible
on windows using meta info), or keep everything the way it is now?
Do you mean simulating case-sensitive paths on case-insensitive file systems ? Why not, depending on the overhead it brings. Unfortunately, I don't have the Windows skills required to work on the subject.
About the overhead the check introduces, note that it is supposed to be temporary. The final goal is to store symbols as-Is, eliminating the need for lowercase conversions. This would remove a lot of allocations and calls to zend_str_tolower_copy(). This would also remove a lot of code.
Hi François,
On Thu, Dec 25, 2014 at 2:40 PM, François Laupretre
francois@tekwire.net wrote:
De : Pierre Joye [mailto:pierre.php@gmail.com]
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC.For those interested, I just created a PR to raise an
E_STRICTmessage on class and function/method case mismatch :https://github.com/php/php-src/pull/965
It is not complete yet, as some cases are not trapped, especially for functions, and the corresponding tests are missing. I'll try to write the RFC (to propose the feature for PHP7) and finish the patch this week. Checking constants is more complex than expected as the namespace part is converted to lowercase during the compile phase. This RFC will deal with classes and functions (including class methods) only.
He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being requested (ie. possible
on windows using meta info), or keep everything the way it is now?Do you mean simulating case-sensitive paths on case-insensitive file systems ? Why not, depending on the overhead it brings. Unfortunately, I don't have the Windows skills required to work on the subject.
About the overhead the check introduces, note that it is supposed to be temporary. The final goal is to store symbols as-Is, eliminating the need for lowercase conversions. This would remove a lot of allocations and calls to zend_str_tolower_copy(). This would also remove a lot of code.
Thanks for putting the RFC together. Let sort that out once and for all :)
I am definitively not in favor of case sensitivity. However it is
still a good thing to have that RFC as this topic keeps pop up once in
a while.
About the patch:
It has to take care about how userland codes (autoloader) will deal
with case insensitive file systems. Will they have to take care of it
themselves? Or will we keep them the way it is now? You can't simulate
case sensitive paths on case insensitive file systems. Some ops may
work, but PHP's IO have to be changed too if we do that, and this is
totally going too far for my taste :)
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Thu, Dec 25, 2014 at 4:40 AM, François Laupretre francois@tekwire.net
wrote:
De : Pierre Joye [mailto:pierre.php@gmail.com]
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC.For those interested, I just created a PR to raise an
E_STRICTmessage on
class and function/method case mismatch :https://github.com/php/php-src/pull/965
It is not complete yet, as some cases are not trapped, especially for
functions, and the corresponding tests are missing. I'll try to write the
RFC (to propose the feature for PHP7) and finish the patch this week.
Checking constants is more complex than expected as the namespace part is
converted to lowercase during the compile phase. This RFC will deal with
classes and functions (including class methods) only.
May I recommend to only target class and class-like names for an initial
RFC? Those have the strongest argument in favor of case-sensitivity given
how current autoloader implementations work - essentially the
case-insensitivity doesn't properly work anyway in modern code.
Constants in particular are more problematic, because they are currently
only partially case-sensitive and there are some constants (namely true,
false and null) where case sensitivity must not be enforced. So if you want
to make constants fully case sensitive those three would have to become
reserved keywords.
So, I think this has more chances if you tackle one issue at a time. I'd
also appreciate having a voting option for removing case-insensitivity
right away, as opposed to throwing E_STRICT/E_DEPRECATED. If we want to
change this, I personally would rather drop it right away than start
throwing E_STRICT warnings that would make the case-insensitive usage
impossible anyway.
Nikita
May I recommend to only target class and class-like names for an initial
RFC? Those have the strongest argument in favor of case-sensitivity given
how current autoloader implementations work - essentially the
case-insensitivity doesn't properly work anyway in modern code.Constants in particular are more problematic, because they are currently
only partially case-sensitive and there are some constants (namely true,
false and null) where case sensitivity must not be enforced. So if you want
to make constants fully case sensitive those three would have to become
reserved keywords.So, I think this has more chances if you tackle one issue at a time. I'd
also appreciate having a voting option for removing case-insensitivity
right away, as opposed to throwing E_STRICT/E_DEPRECATED. If we want to
change this, I personally would rather drop it right away than start
throwingE_STRICTwarnings that would make the case-insensitive usage
impossible anyway.
At the very least that sounds like a less intrusive step, as methods and
classes are usually already written "correctly".
Hi!
At the very least that sounds like a less intrusive step, as methods and
classes are usually already written "correctly".
To me, it sounds like needless nuisance - the code works, but wastes
time to produce warnings that nobody reads. If your have a code that
relies on autoloaders and case mix breaks it, your autoloading code can
take care of it and produce whatever handling you need (from log
messages up to bailing out). But if you have the code that uses mixed
case and it works for you, these warnings would do nothing - they'd just
be ignored and we'd hurt performance and achieve nothing.
Stas Malyshev
smalyshev@gmail.com
Hi!
At the very least that sounds like a less intrusive step, as methods and
classes are usually already written "correctly".To me, it sounds like needless nuisance - the code works, but wastes
time to produce warnings that nobody reads. If your have a code that
relies on autoloaders and case mix breaks it, your autoloading code can
take care of it and produce whatever handling you need (from log
messages up to bailing out). But if you have the code that uses mixed
case and it works for you, these warnings would do nothing - they'd just
be ignored and we'd hurt performance and achieve nothing.
My point too. I was only referring to the options for the RFC.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 20/12/2014 23:01, F & N Laupretre a écrit :
Hi,
I don't know if this was discussed before. So, tell me what you
think before I write an RFC.I would like to propose that namespaces, functions, and classes
become case-sensitive (constants are already case-sensitive).
Actually, I never understood why they are case-insensitive. Even if
the performance gain is negligible, I think it could be the right
time to question this.
- -1
Huge BC, no value.
Yes, I'm aware that some autoloader introduce case-sensitivity.
Please fix your autoloader.
I really don't think this is something which have to be fixed in PHP.
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlSZIIYACgkQYUppBSnxahiRagCeNpa5SexT3DLWbOou2AHEeXsN
MxwAoMC2+d/Q4pvmjLnaV9e4W9mApplI
=TCfk
-----END PGP SIGNATURE
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F & N Laupretre nf.laupretre@yahoo.fr
wrote:
I don't know if this was discussed before. So, tell me what you think
before
I write an RFC.I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.
I'm writing this mail without reading current zend code.
Anyway, is it feasible to raise E_DEPRECATE without much performance
penalty?
For example,
if (!strcmp(name, name_to_be_searched)) {
do_something;
} else if (!strcasecmp(name, name_to_be_searched) {
rase_error;
do_something;
}
Duplicated codes may be removed by macro. strcasecmp() checks may be removed
10 years later or more.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the performance gain is
negligible, I think it could be the right time to question this.I'm writing this mail without reading current zend code.
Anyway, is it feasible to raise E_DEPRECATE without much performance
penalty?
For example,if (!strcmp(name, name_to_be_searched)) {
do_something;
} else if (!strcasecmp(name, name_to_be_searched) {
rase_error;
do_something;
}Duplicated codes may be removed by macro.
strcasecmp()checks may be
removed
10 years later or more.
Unfortunately, raising an E_DEPRECATED on case-sensitive mismatch is a huge work, as case-insensitivity appears in a lot of locations throughout the core. And the macro approach is not possible.
Actually, case insensitivity goes well beyond class and function names: it also includes namespaces, scope resolution operators (self, parent, static), class magic methods, method names (properties are already case-sensitive), language keywords, and some stream wrapper protocols (like file and zlib). All these case insensitive comparisons are done in a variety of ways, at various locations in the code. Most store and compare names converted to lowercase (which implies a problem with Unicode as correct conversion with an unknown character set is impossible), some use strncasecmp...
So, making the code case-sensitive would be a important work, but raising an E_DEPRECATED message would require much more work. Unfortunately, you can forget the idea of a macro that can be removed anytime in the future :)
Cheers
François