Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F N Laupretre nf.laupre...@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
yohg...@ohgaki.net
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi,
De : yohg...@gmail.com [mailto:yohg...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote: 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. I see case (in)sensetivity in names of functions/classes/... as being separate from case sensetivity in file names. There is already a problem for those who develop on MS-Windows/Mac and deploy on *nix - a typeo can lead to a failure at run time. The fix is simple, people do not complain that PHP should protect them from this. I am a believer in simplicity, which is part of the reason that I support the idea of removing the complexity of case insensitivity in function/... names. Case folding has a slight speed penalty and does not work properly. It does not fold unicode characters outside the range U+40 - U+7A (ie US ASCII), so best to just forget it. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Thu, Dec 25, 2014 at 9:05 PM, Alain Williams a...@phcomp.co.uk wrote: On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote: 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. I see case (in)sensetivity in names of functions/classes/... as being separate from case sensetivity in file names. There is already a problem for those who develop on MS-Windows/Mac and deploy on *nix - a typeo can lead to a failure at run time. The fix is simple, people do not complain that PHP should protect them from this. I am a believer in simplicity, which is part of the reason that I support the idea of removing the complexity of case insensitivity in function/... names. Case folding has a slight speed penalty and does not work properly. It does not fold unicode characters outside the range U+40 - U+7A (ie US ASCII), so best to just forget it. I do not see a reason why some code having ran out of the box for more than a decade should be changed for 7 for purely syntax sugars reason, like ImageCreate to imagecreate or the likes. It just does not make sense to me. Ignoring the paths issue, related to classes, autoload, etc. also sounds very weird to me. Anyway, let get a RFC ready, a patch that does not break anything (well, except the case issue :) ), almost everything about this topic else has been said already. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Thu, Dec 25, 2014 at 10:18:13PM +1100, Pierre Joye wrote: Forgot reply all? :) Yes - thanks. Reformatted: On Thu, Dec 25, 2014 at 09:53:11PM +1100, Pierre Joye wrote: I do not see a reason why some code having ran out of the box for more than a decade should be changed for 7 for purely syntax sugars reason, like ImageCreate to imagecreate or the likes. It just does not make sense to me. What you are saying is: a mistake was made 10 years ago, we will pass up an opportunity to fix it and perpetuate the error for ever. Ignoring the paths issue, related to classes, autoload, etc. also sounds very weird to me. It is bringing in complexity that is not needed. Regards -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Thu, Dec 25, 2014 at 4:40 AM, François Laupretre franc...@tekwire.net wrote: De : Pierre Joye [mailto:pierre@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. 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
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Dec 25, 2014 7:08 PM, Nikita Popov nikita@gmail.com wrote: 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. At the very least that sounds like a less intrusive step, as methods and classes are usually already written correctly.
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Dec 26, 2014 4:58 AM, Stanislav Malyshev smalys...@gmail.com wrote: 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.
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
De : Pierre Joye [mailto:pierre@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi François, On Thu, Dec 25, 2014 at 2:40 PM, François Laupretre franc...@tekwire.net wrote: De : Pierre Joye [mailto:pierre@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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
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@gmail.com: On Tue, Dec 23, 2014 at 2:17 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Dec 20, 2014 at 11:01 PM, F N Laupretre nf.laupre...@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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Tue, Dec 23, 2014 at 9:00 AM, Maxime Veber nek@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
De : Pierre Joye [mailto:pierre@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
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 larue...@php.net To: Pierre Joye pierre@gmail.com Cc: Mike Dugan m...@mjdugan.com, Andrea Faulds a...@ajf.me, Marco Pivetta ocram...@gmail.com, PHP internals internals@lists.php.net, David Muir davidkm...@gmail.com, Paul Dragoonis dragoo...@gmail.com, nf.laupre...@yahoo.fr nf.laupre...@yahoo.fr, Kevin Israel pleasest...@live.com Sent: Mon, 22 Dec 2014 6:25 AM Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols On Mon, Dec 22, 2014 at 12:35 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan m...@mjdugan.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
De : Pierre Joye [mailto:pierre@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 at 10:18:29AM +0100, Lester Caine wrote: 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? This issue is about user written functions. Here names are only partly case insensitive. If a function is written with in its name U+00C1 (Capital letter A with acute) but called with U+00E1 (Latin Small Letter A with acute) it will not be found. So we can only say that some letters are case insensitive - this is what I called ''US ASCII chauvinism''. See: http://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block) -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Dec 22, 2014 4:33 PM, F N Laupretre nf.laupre...@yahoo.fr wrote: 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.
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi all, On Mon, Dec 22, 2014 at 8:33 AM, David Muir davidkm...@gmail.com wrote: +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. It seems the most reasonable approach for this issue. +1 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Sat, Dec 20, 2014 at 11:01 PM, F N Laupretre nf.laupre...@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
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
+1 for adding E_DEPRECATED and removing support in PHP 8. On Mon, Dec 22, 2014 at 11:17 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Dec 20, 2014 at 11:01 PM, F N Laupretre nf.laupre...@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 -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 at 11:40:33PM -0200, guilhermebla...@gmail.com wrote: +1 for adding E_DEPRECATED and 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Tue, Dec 23, 2014 at 2:17 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Dec 20, 2014 at 11:01 PM, F N Laupretre nf.laupre...@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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
-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- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Sun, Dec 21, 2014 at 04:20:13PM +1100, Pierre Joye wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 20 December 2014 22:44:24 GMT, Alain Williams a...@phcomp.co.uk wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 21 Dec 2014, at 10:32 am, Kevin Israel pleasest...@live.com wrote: On 12/20/2014 05:16 PM, Paul Dragoonis wrote: 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. On 20 Dec 2014 22:01, F N Laupretre nf.laupre...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hey, On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 December 2014 at 01:43, Andrea Faulds a...@ajf.me wrote:
Hey,
On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote:
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
http://twitter.com/Ocramius
http://ocramius.github.com/
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:43, Andrea Faulds a...@ajf.me wrote: Hey, On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 December 2014 at 01:52, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:43, Andrea Faulds a...@ajf.me wrote: Hey, On 21 Dec 2014, at 23:33, David Muir davidkm...@gmail.com wrote: 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 http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 22 Dec 2014, at 03:58, Pierre Joye pierre@gmail.com wrote: On Dec 22, 2014 8:03 AM, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:52, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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. Mike Dugan Sent from my iPhone On Dec 21, 2014, at 11:00 PM, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 03:58, Pierre Joye pierre@gmail.com wrote: On Dec 22, 2014 8:03 AM, Marco Pivetta ocram...@gmail.com wrote: On 22 December 2014 at 01:52, Andrea Faulds a...@ajf.me wrote: On 22 Dec 2014, at 00:50, Marco Pivetta ocram...@gmail.com wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan m...@mjdugan.com wrote: 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 :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Mon, Dec 22, 2014 at 12:35 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Dec 22, 2014 at 3:05 PM, Mike Dugan m...@mjdugan.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
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 On 20 Dec 2014 22:01, F N Laupretre nf.laupre...@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. Regards Francois
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Sat, Dec 20, 2014 at 11:01:23PM +0100, F N Laupretre 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hey François, (I assume there’s a ç, I apologise if not) On 20 Dec 2014, at 22:01, F N Laupretre nf.laupre...@yahoo.fr wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Sat, Dec 20, 2014 at 10:45:39PM +, Andrea Faulds wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hey Alain, On 20 Dec 2014, at 22:52, Alain Williams a...@phcomp.co.uk wrote: On Sat, Dec 20, 2014 at 10:45:39PM +, Andrea Faulds wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On 12/20/2014 05:16 PM, Paul Dragoonis wrote: 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. On 20 Dec 2014 22:01, F N Laupretre nf.laupre...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F N Laupretre nf.laupre...@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
yohg...@ohgaki.net
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
De : Andrea Faulds [mailto:a...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
I just read Nikita's RFC on deprecated features for PHP 7. Couldn't we go this way and use his process ? add to his list the fact that functions, classes, and namespaces can be declared and used/called with case-sensitivity mismatches ? This would become clearly known by everyone. Then, as any other deprecated feature, raise an E_STRICT warning in 5.7, and deprecate it in 7. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi! 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 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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
On Sun, Dec 21, 2014 at 9:01 AM, F N Laupretre nf.laupre...@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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
