Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update
Hi Levi, On Sat, Feb 7, 2015 at 7:05 AM, Levi Morrison morrison.l...@gmail.com wrote: I have updated the RFC for removing PHP 4 constructors[1]. Notably, I have pushed off the removal to PHP 8, and instead only deprecate them in PHP 7. The rationale is that eventual consistency in this matter is good enough for now, and going slow may help avoid a Python 2 vs 3 type disaster where older libraries aren't updated fast enough. I intend to put this to vote soon, as we are approaching the March feature freeze, so please chime in if you have been wanting to voice your opinion and haven't. I thought I filed this as Trait bug, but it isn't the bug db. I might forget to report it. http://3v4l.org/pL3Hr Class calls trait function that is PHP4 constructor. This could be resolved by removing PHP4 constructor. Could this issue be resolved in PHP7? Even if previous issue could be resolved, we have http://3v4l.org/G7DOC PHP4 constructor is harmful. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update
On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati p...@beccati.com wrote: Hi Levi, I have updated the RFC for removing PHP 4 constructors[1]. Notably, I have pushed off the removal to PHP 8, and instead only deprecate them in PHP 7. The rationale is that eventual consistency in this matter is good enough for now, and going slow may help avoid a Python 2 vs 3 type disaster where older libraries aren't updated fast enough. I intend to put this to vote soon, as we are approaching the March feature freeze, so please chime in if you have been wanting to voice your opinion and haven't. Over-long email - sorry about it! ;) I strongly opposed this RFC in past. I've also seen people suggesting to grumpy old men like me that the time spent complaining was probably enough to fix our legacy codebases to replace PHP4-constructors. That is certainly not true in my case, but I've decided to accept the challenge and build a tool to convert PHP4-constructors to __construct, automating the required tasks as much as possible. Such work is an ongoing PR to PHP-CS-Fixer[1], which will hopefully be merged in the next few weeks. I've advertised it before, but I'd like to do it again, as I think it greatly reduces the impact of the BC break of your RFC. I've ran it on the (legacy) open source application I maintain and it detected and converted most of the classes[2]: 962 changed files with 351 additions and 884 deletions. The only manual changes I had to do were fixing a few calls to the grandparent constructors[3]. What I can tell from this experience is that dropping PHP4-constructors shouldn't be quite as bad as I thought it was, at least now that there's a tool that does most of the job for you. Adapting (all of) PEAR should be fairly straightforward in case someone is willing to do that. thanks for looking into this and taking your time to help with the migration! The real challenge I will have to face in the future is the removal of Scoped calls of non-static methods from incompatible $this context, which has been applied and temporarily reverted soon after. Many PEAR (and possibly non-PEAR) classes in our codebase have methods that have been designed to work both as static/non-static methods[4] which won't soon work any more in PHP7. Granted, I've voted yes on this one and I still would today, but I'd expect that fixing that code once the revert is reverted is going to be much trickier than just renaming a bunch of constructors. we discussed this related to PEAR and Nikita agreed that the original implementation of the removal was too strict: http://chat.stackoverflow.com/transcript/11?m=21058930#21058930 and he even come up with an alternative solution: https://github.com/php/php-src/pull/1026 (not sure why didn't he merged or announced it for discussion yet). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update
Hi Levi, I have updated the RFC for removing PHP 4 constructors[1]. Notably, I have pushed off the removal to PHP 8, and instead only deprecate them in PHP 7. The rationale is that eventual consistency in this matter is good enough for now, and going slow may help avoid a Python 2 vs 3 type disaster where older libraries aren't updated fast enough. I intend to put this to vote soon, as we are approaching the March feature freeze, so please chime in if you have been wanting to voice your opinion and haven't. Over-long email - sorry about it! ;) I strongly opposed this RFC in past. I've also seen people suggesting to grumpy old men like me that the time spent complaining was probably enough to fix our legacy codebases to replace PHP4-constructors. That is certainly not true in my case, but I've decided to accept the challenge and build a tool to convert PHP4-constructors to __construct, automating the required tasks as much as possible. Such work is an ongoing PR to PHP-CS-Fixer[1], which will hopefully be merged in the next few weeks. I've advertised it before, but I'd like to do it again, as I think it greatly reduces the impact of the BC break of your RFC. I've ran it on the (legacy) open source application I maintain and it detected and converted most of the classes[2]: 962 changed files with 351 additions and 884 deletions. The only manual changes I had to do were fixing a few calls to the grandparent constructors[3]. What I can tell from this experience is that dropping PHP4-constructors shouldn't be quite as bad as I thought it was, at least now that there's a tool that does most of the job for you. Adapting (all of) PEAR should be fairly straightforward in case someone is willing to do that. The real challenge I will have to face in the future is the removal of Scoped calls of non-static methods from incompatible $this context, which has been applied and temporarily reverted soon after. Many PEAR (and possibly non-PEAR) classes in our codebase have methods that have been designed to work both as static/non-static methods[4] which won't soon work any more in PHP7. Granted, I've voted yes on this one and I still would today, but I'd expect that fixing that code once the revert is reverted is going to be much trickier than just renaming a bunch of constructors. So, given the level of breakages that legacy apps are going to endure anyway, I'd be ok with this RFC targeting PHP7 too. Cheers [1] https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970 [2] http://qrurl.it/r/kz5 [3] http://qrurl.it/r/kz6 [4] https://github.com/pear/pear-core/blob/stable/PEAR.php#L303 -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Remove PHP 4 Constructors Update
Dear Internals, I have updated the RFC for removing PHP 4 constructors[1]. Notably, I have pushed off the removal to PHP 8, and instead only deprecate them in PHP 7. The rationale is that eventual consistency in this matter is good enough for now, and going slow may help avoid a Python 2 vs 3 type disaster where older libraries aren't updated fast enough. I intend to put this to vote soon, as we are approaching the March feature freeze, so please chime in if you have been wanting to voice your opinion and haven't. Cheers, Levi Morrison [1] https://wiki.php.net/rfc/remove_php4_constructors -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com: Kristopher wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+ tmatgqrb7yqeips11...@mail.gmail.com... On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary Yet you seem to have no problem wasting loads of time arguing about it on the internet. Because I would rather fight for valid principles than give in. To quote Emiliano Zapata It is better to die on your feet than live on your knees. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php By this time, you could have opened your project/projects in any Regex search and replace capable editor/IDE, wrote a pattern that matches class name with a method name same as class name and replaces it with __construct. Takes about 5-10 minutes for the first project to get it right, ensures forward compatibility since 5.0.0 and saves your employer all those hours that you just spend arguing. Or just write a PHP script that does the same - even easier and faster...
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
2015-01-22 15:22 GMT+02:00 Arvids Godjuks arvids.godj...@gmail.com: 2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com: Kristopher wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+ tmatgqrb7yqeips11...@mail.gmail.com... On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary Yet you seem to have no problem wasting loads of time arguing about it on the internet. Because I would rather fight for valid principles than give in. To quote Emiliano Zapata It is better to die on your feet than live on your knees. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php By this time, you could have opened your project/projects in any Regex search and replace capable editor/IDE, wrote a pattern that matches class name with a method name same as class name and replaces it with __construct. Takes about 5-10 minutes for the first project to get it right, ensures forward compatibility since 5.0.0 and saves your employer all those hours that you just spend arguing. Or just write a PHP script that does the same - even easier and faster... Omg, a folowup. I just found a gem in the docs: As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor. This change doesn't affect non-namespaced classes. Can be read here: http://lv.php.net/manual/en/language.oop5.decon.php So, I think this seals the deal :)
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Arvids Godjuks wrote in message news:CAL0xaBFDOP0402T06DJLjbmv6CgsS+xcnY69=szrzts5br5...@mail.gmail.com... 2015-01-22 15:22 GMT+02:00 Arvids Godjuks arvids.godj...@gmail.com: 2015-01-21 19:21 GMT+02:00 Tony Marston tonymars...@hotmail.com: Kristopher wrote in message news:CAF9U7z_BLDusnq7c0mVToxyJpqOpa+ tmatgqrb7yqeips11...@mail.gmail.com... On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: You are totally missing the point. It is the principle of having to spend unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fix a bug or a security issue, therefore it is frivolous and unnecessary Yet you seem to have no problem wasting loads of time arguing about it on the internet. Because I would rather fight for valid principles than give in. To quote Emiliano Zapata It is better to die on your feet than live on your knees. By this time, you could have opened your project/projects in any Regex search and replace capable editor/IDE, wrote a pattern that matches class name with a method name same as class name and replaces it with __construct. Takes about 5-10 minutes for the first project to get it right, ensures forward compatibility since 5.0.0 and saves your employer all those hours that you just spend arguing. Or just write a PHP script that does the same - even easier and faster... Omg, a folowup. I just found a gem in the docs: As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor. This change doesn't affect non-namespaced classes. Can be read here: http://lv.php.net/manual/en/language.oop5.decon.php So, I think this seals the deal :) You are missing one important detail. That section only applies if I use namespaces, and - guess what - I DON'T. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, Jan 21, 2015 at 12:21 PM, Tony Marston tonymars...@hotmail.com wrote: Because I would rather fight for valid principles than give in. To quote Emiliano Zapata It is better to die on your feet than live on your knees. I don't think constructors are what he had in mind.
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Kristopher wrote in message news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com... On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary Yet you seem to have no problem wasting loads of time arguing about it on the internet. Because I would rather fight for valid principles than give in. To quote Emiliano Zapata It is better to die on your feet than live on your knees. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Jan 22, 2015 12:21 AM, Tony Marston tonymars...@hotmail.com wrote: Kristopher wrote in message news:caf9u7z_bldusnq7c0mvtoxyjpqopa+tmatgqrb7yqeips11...@mail.gmail.com... On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary Yet you seem to have no problem wasting loads of time arguing about it on the internet. Because I would rather fight for valid principles than give in. To quote Emiliano Zapata It is better to die on your feet than live on your knees. I think we get the message. It arguably adds any value to this discussion to repeat the same thing over and over. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Kristopher wrote in message news:CAF9U7z-bkYRDwAL8CA4_=1dhorl0evp_mzwf6qwqscwdf7n...@mail.gmail.com... On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston tonymars...@hotmail.com wrote: @tony: What's really interesting is that all this time you've spent arguing could have been used to update your code and make this no longer an issue for you. You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary @everyone: Would an RFC be necessary to update the PHP manual to actually recommend the PHP 5 constructors and recommend against using the PHP 4 style constructors, using very explicit language? If not, should this change be made, regardless of the outcome of the RFC to remove PHP 4 constructors? You cannot remove anything from the language until after it has been marked a deprecated, and the simple fact is that PHP 4 constructors have NEVER been marked as deprecated. I have used every PHP 5 release up to and including the latest (5.6..4) with error_reporting set to E_ALL and all my code has run without producing any error messages. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
François Laupretre wrote in message news:018d01d03501$c0a877d0$41f96770$@tekwire.net... De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part I'm happy to update the manual, but I think I'd want more of a consensus (not necessarily a formal RFC, but at least a straw poll) for soft deprecation (to reuse the term we used for mysql_* before it started generating E_DEPRECATED messages but was deprecated in the manual) before making the change. +1 to deprecate feature. I am generally favorable to BC but developers had 10 years to adapt to the new syntax and the change is trivial. Why should we have to change our code to adapt to new syntax when the old syntax has NEVER been marked as deprecated? Using this logic must we also change our code to replace all occurrences of the old long syntax for arrays with the new short syntax? If we plan changes like this for php 7, we'll have to reconsider our position on 5.7. Users will never upgrade to any new version of PHP which does not contain either bug fixes or new features. The proposal for 5.7 was for it to contain nothing but a new set of deprecated notices. François -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Ralf Lang wrote in message news:54beb145.7030...@b1-systems.de... #1 and #2 may be considered to be genuine improvements by the user community, but #3 most certainly will not. It does not matter how you try to dress it up, forcing your end users to jump through hoops before they can upgrade is a customer relations disaster. PHP and other scripting languages have done it before. They will do it again. That's precisely the point I am trying to make. Too many frivolous BC breaks cause more problems than they fix. From time to time, major release really means some rare cases won't work as before and require manual intervention to make work again. It's not php-exclusive. Hell, even in the linux kernel, drivers and infrastructure from bottom to top we see it every day. Design changes, things break, fix or perish. Those BC breaks were necessary and not frivolous. 1995 HTML will probably not look exactly as intended when browsed with today's browsers. But at least they will still appear and not simply produce a blank page. Chances are, even your 20 year old C or C++ code won't compile on the latest gcc without some trivial changes or some additional compile options and even if it does, it will violate some widely accepted policy. In distribution packaging, we face the latter more often than you think. This is especially true with feature-complete software dinosaurs. Trivial changes because of necessary BC breaks I can live with, but monumental changes due to frivolous BC breaks just make me mad! Software needs maint. to keep it alive in an ever changing environment of hardware, OS, platform libraries etc. If PHP decides to drop PHP4 constructors in PHP7, which is 2 and a half major releases later, The number of releases later is irrelevant. PHP 4 constructors have NEVER been marked as deprecated, therefore they are still fully supported and not obsolete. And I still say that their removal is entirely frivolous and unnecessary. then you can run your older PHP, you can add support via an extension or fork or you can do trivial changes to your libraries. Each has its own costs. Doing nothing also has costs. A minor cost to the core developers is far better than a major cost to the 240 million websites out there in userland. I have to maintain some customer apps on a PHP4-based framework (version). It hasn't been fun to keep it working on PHP5.3++ and it won't be fun on PHP7 either. It's just the way it is. I think the customer will be charged a lot of support hours but he will get a much better product. How can the move from the old to the new constructors add any value to product? It certainly would not make it run faster or produce better results. In theory, I could just run older PHP releases but in practice, I wont. I also want to be able to run the latest PHP release so that I can gain access to all those bug fixes, but a constant flow of frivolous BC breaks makes this very difficult. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary Yet you seem to have no problem wasting loads of time arguing about it on the internet. You cannot remove anything from the language until after it has been marked a deprecated, and the simple fact is that PHP 4 constructors have NEVER been marked as deprecated. I have used every PHP 5 release up to and including the latest (5.6..4) with error_reporting set to E_ALL and all my code has run without producing any error messages. I don't even know what you're responding to here; I didn't suggest removing it from the language, nor that it was deprecated. I suggested updating the manual to discourage use. This is a baby step toward actual deprecation. 1) discourage use of it on the website, 2) provide deprecation notices in a future version of PHP, 3) sometime in the distant future, actually remove it. On Wed, Jan 21, 2015 at 9:50 AM, Tony Marston tonymars...@hotmail.com wrote: Kristopher wrote in message news:CAF9U7z-bkYRDwAL8CA4_= 1dhorl0evp_mzwf6qwqscwdf7n...@mail.gmail.com... On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston tonymars...@hotmail.com wrote: @tony: What's really interesting is that all this time you've spent arguing could have been used to update your code and make this no longer an issue for you. You are totally missing the point. It is the principle of having to spent unknown quantities of time in refactoring my code for nothing more than a frivolous and unnecessary break in BC. It does not fi a bug or a security issue, therefore it is frivolous and unnecessary @everyone: Would an RFC be necessary to update the PHP manual to actually recommend the PHP 5 constructors and recommend against using the PHP 4 style constructors, using very explicit language? If not, should this change be made, regardless of the outcome of the RFC to remove PHP 4 constructors? You cannot remove anything from the language until after it has been marked a deprecated, and the simple fact is that PHP 4 constructors have NEVER been marked as deprecated. I have used every PHP 5 release up to and including the latest (5.6..4) with error_reporting set to E_ALL and all my code has run without producing any error messages. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Rowan Collins wrote in message news:54bd4d98.80...@gmail.com... Tony Marston wrote on 19/01/2015 16:24: Rowan Collins wrote in message news:54bd240a.7050...@gmail.com... Tony Marston wrote on 19/01/2015 15:01: The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. I am not ignoring the grievances, and have repeatedly said that I am not sure whether or not the change is justified in this case. You, however, are ignoring the benefits, and have repeatedly used phrasing that implies that you do not think they exist, right underneath my messages explaining what they are. There may be a small benefit to the core developers, but a huge negative benefit (i.e. problem) to the rest of the PHP community. When you identify something that benefits both the core developers and their customers I might be more inclined to listen. Anything that benefits the core developers in their task of maintaining and improving the core automatically benefits users, because the core is improved. The idea that the two interests are distinct, or even opposed to each other, is disingenuous to the people who volunteer their time in an honest effort to make PHP better for everyone. I disagree. The two interests *ARE* distinct because the term improvement is measured differently by each group. For the core developers it means easier maintenance, but for the end users it means something which they can see for themselves. There appear to be three types of improvement which are offered by the core developers: (1) Install this upgrade and your application will either run faster or benefit from some bug fixes. (2) Install this upgrade and, although your application will still run as it did before, you won't be able to get any benefit from new features until you change your code. (3) Install this upgrade and your application will stop working until you change your code. #1 and #2 may be considered to be genuine improvements by the user community, but #3 most certainly will not. It does not matter how you try to dress it up, forcing your end users to jump through hoops before they can upgrade is a customer relations disaster. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston tonymars...@hotmail.com wrote: @tony: What's really interesting is that all this time you've spent arguing could have been used to update your code and make this no longer an issue for you. @everyone: Would an RFC be necessary to update the PHP manual to actually recommend the PHP 5 constructors and recommend against using the PHP 4 style constructors, using very explicit language? If not, should this change be made, regardless of the outcome of the RFC to remove PHP 4 constructors?
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 20 January 2015 at 07:09, Kristopher kristopherwil...@gmail.com wrote: @everyone: Would an RFC be necessary to update the PHP manual to actually recommend the PHP 5 constructors and recommend against using the PHP 4 style constructors, using very explicit language? If not, should this change be made, regardless of the outcome of the RFC to remove PHP 4 constructors? I'm happy to update the manual, but I think I'd want more of a consensus (not necessarily a formal RFC, but at least a straw poll) for soft deprecation (to reuse the term we used for mysql_* before it started generating E_DEPRECATED messages but was deprecated in the manual) before making the change. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Remove PHP 4 Constructors
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part I'm happy to update the manual, but I think I'd want more of a consensus (not necessarily a formal RFC, but at least a straw poll) for soft deprecation (to reuse the term we used for mysql_* before it started generating E_DEPRECATED messages but was deprecated in the manual) before making the change. +1 to deprecate feature. I am generally favorable to BC but developers had 10 years to adapt to the new syntax and the change is trivial. If we plan changes like this for php 7, we'll have to reconsider our position on 5.7. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
#1 and #2 may be considered to be genuine improvements by the user community, but #3 most certainly will not. It does not matter how you try to dress it up, forcing your end users to jump through hoops before they can upgrade is a customer relations disaster. PHP and other scripting languages have done it before. They will do it again. From time to time, major release really means some rare cases won't work as before and require manual intervention to make work again. It's not php-exclusive. Hell, even in the linux kernel, drivers and infrastructure from bottom to top we see it every day. Design changes, things break, fix or perish. 1995 HTML will probably not look exactly as intended when browsed with today's browsers. Chances are, even your 20 year old C or C++ code won't compile on the latest gcc without some trivial changes or some additional compile options and even if it does, it will violate some widely accepted policy. In distribution packaging, we face the latter more often than you think. This is especially true with feature-complete software dinosaurs. Software needs maint. to keep it alive in an ever changing environment of hardware, OS, platform libraries etc. If PHP decides to drop PHP4 constructors in PHP7, which is 2 and a half major releases later, then you can run your older PHP, you can add support via an extension or fork or you can do trivial changes to your libraries. Each has its own costs. Doing nothing also has costs. I have to maintain some customer apps on a PHP4-based framework (version). It hasn't been fun to keep it working on PHP5.3++ and it won't be fun on PHP7 either. It's just the way it is. I think the customer will be charged a lot of support hours but he will get a much better product. In theory, I could just run older PHP releases but in practice, I wont. I am in favor of the change but I am currently not technically able to vote. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hello Andrea, On Thu, Jan 15, 2015 at 10:55 AM, Andrea Faulds a...@ajf.me wrote: Hey Levi, Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Thoughts? I would be against a deprecation notice here. In fact I think it should either be do nothing or remove them entirely. I know this thread has become out of control but as a user of PHP 3, 4 and 5; a framework developer; and a engineering executive I find that the PHP 4 style constructors to be an ignorance that I am forced to currently deal with. The amount of information in this post is vast and I don't feel I need to go into details. However, I support this proposal 100% as do I feel most of the open source community. Items that are still out there relying on PEAR and other packages should remain on PHP 5 or even less. We have better solutions now such as composer which has changed the ecosystems reliance on items such as PEAR. Developers that are relying on PEAR have other issues to date than simply what would happen with PHP 7 as not all PEAR packages work well with PHP 5 at this time especially the latest releases. PEAR is a thing that has come and gone. Legacy code that still remains with PHP 4 style constructors should upgrade to the latest. Language evolve and we need to keep pushing the bar forward. As a personal note, PHP has slowly been moving towards the background for certain applications for JavaScript (nodejs) and I feel for PHP to remain it's competitive market it needs to evolve more as a leading language. PHP was great about this between 3, 4 and 5. 7 must do the same thing otherwise I feel like it will lead to a slow death much like the perl of old. Regards, Mike
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Andrey Andreev wrote in message news:caphkizzytddn2b_e84ygk3xhiudgh-m0jtqdlo85cy3pc8c...@mail.gmail.com... On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston tonymars...@hotmail.com wrote: snip Talk about ignorance ... you've ignored the new style of coding for a decade and don't want to be bothered to adapt to it for another one. It is not up to the language developers to dictate what style of coding individual developers should or should not use. It is up to you to provide a library of features, and it is up to the individual developer to decide how to structure those functions into a coherent program. There is no such thing as a single proper style which is universally accepted and can be universally enforced. TFM clearly favors __construct(), and it does it for a reason. The fact that the manual prefers the new kind of constructor does not mean that I am forced to use it. PHP 5.6.4 still supports the use of the old constructors without issuing any deprecated notices so that means that they are fully supported. I still use PHP 4 constructors for the simple reason that I developed my open source framework using PHP 4, and when PHP 5 came out I had to support both versions at the same time for many years until PHP 4 actually died. I had no real need to change the constructors, so I did not see any need to spend time in fixing what was not broken. No matter the cause, if the feature causes issues for the majority of PHP developers, A vociferous group of developers, yes, but how can you prove that this is the majority? And the issues are not due to bugs in the language itself but their failure to fully understand how the language actually works. you can't just give them the finger because you don't want to spend a few hours renaming Foo::foo() to Foo::__construct(). I should not have to spend any time at all in fixing what shouldn't have been broken in the first place. Arguing about BC breaks is one thing, but don't excuse your own ignorance with others' lack of knowledge, when they've clearly been driven into that. Excuse me? How can others' lack of knowledge be down to ignorance on my part? It is their lack of knowledge which caused them to make newbie mistakes. Developers with more experience would not make such fundamental mistakes. PHP 4 style coding is just unknown to the majority of users today and But not for those users who started developing with PHP before version 5 became mainstream. Your attitude seems to be Let's ignore those boring old farts who made the language what it is today and instead start pandering to a bunch of ignorant newbies. Oh, right ... cause pandering to the ignorant old farts is better than pandering to the ignorant newbies. It is your job to pander to the wishes of all your customers, both old and new. Alienating your loyal and long-standing customer base just to pander to the whims of a bunch of ignorant newbies who can't be bothered to RTFM is not the way to achieve this. You need to maintain a balance, and this means not letting the pendulum swing too far in favour of one over the other. Neither is better, of course. However, it's not me who suggested anything about pandering to a certain group, and you're in the minority, I may be in a minority among the people who have joined in this particular discussion, but what figures do you have regarding the number of websites of the 240 million out there that will be affected by this proposed change and who would voice their complaint if they knew about it? The only way they can currently register their disapproval of your constant stream of BC breaks is by not updating to the new version as soon as it is released. This is why 20% of PHP sites are still stuck on version 5.2 and 45% on version 5.3. That shows exactly how popular your releases with BC breaks really are if 65% of websites can't upgrade because of BC breaks. so you probably don't want to go there - being born earlier doesn't give you the advantage. It gives me the advantage of experience. most people assume that it is no longer supported Then most people assumed wrongly. Why should one section of the PHP community be made to suffer because of a wrong assumption made by another part of the community? Again, you're putting this out of context. How? I'm quoting exactly what you wrote in the way that you wrote it. I am not mixing and matching words from different sentences to produce a sentence that you did not actually write. (or rather, that it was never supported, because they don't even know it existed). Just because a bunch of newbies didn't realise that a feature existed is no reason to remove that feature. There are functions in the language that I don't use and have no desire to use, but do you see me advocating for their removal? You would be, if they were causing you problems. But that's the whole point. I have been using PHP 4 constructors with PHP
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi, On Mon, Jan 19, 2015 at 5:01 PM, Tony Marston tonymars...@hotmail.com wrote: But the only benefits with the removal of old features is a smaller code base for the core developers. The only benefit which is experienced in userland is that applications which have run for over a decade suddenly stop working. Ah, so you admit there may be benefits? Again, I do not say that those benefits are definitely enough to justify the change in this case, but they are real, and I would like you to stop dismissing them. There is a big difference if a BC break which causes a minor benefit to the core developers also causes a major headache to the millions of developers who are the customers, the people who use the language to develop applications. The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. You continue doing exactly what you were asked not to. It's not just a minor benefit to the core developers. It's an extremely unpopular feature that often leads to debugging nightmares even for users with enough experience to take on senior development roles. PHP 4 style coding is just unknown to the majority of users today and most people assume that it is no longer supported (or rather, that it was never supported, because they don't even know it existed). You're obviously an exception to that, and you might argue that somebody's lack of knowledge isn't an excuse to break all of your code, but please stop arguing that a handful of core PHP developers decided to drop a feature for their own benefit alone. That is simply not true. Also, I haven't seen PHP4 style constructors used in years and you're making it sound like every PHP application on the internet uses them - very far from it. That being said, it is still a major BC issue and unfortunately we're not going to have PHP 5.7 where it could've been deprecated, so I guess being stuck with this feature (but deprecated) in PHP7 might be the wiser choice. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Rowan Collins wrote in message news:54bce8f5.5080...@gmail.com... Tony Marston wrote on 19/01/2015 10:37: Rowan Collins wrote in message news:calkijkr3os6ta55rjlq61o1+on-s3j8xfzmhjvqfxozlzwt...@mail.gmail.com... snip But the only benefits with the removal of old features is a smaller code base for the core developers. The only benefit which is experienced in userland is that applications which have run for over a decade suddenly stop working. Ah, so you admit there may be benefits? Again, I do not say that those benefits are definitely enough to justify the change in this case, but they are real, and I would like you to stop dismissing them. There is a big difference if a BC break which causes a minor benefit to the core developers also causes a major headache to the millions of developers who are the customers, the people who use the language to develop applications. The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Tony Marston wrote on 19/01/2015 15:01: The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. I am not ignoring the grievances, and have repeatedly said that I am not sure whether or not the change is justified in this case. You, however, are ignoring the benefits, and have repeatedly used phrasing that implies that you do not think they exist, right underneath my messages explaining what they are. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 19 Jan 2015, at 10:05, Tony Marston tonymars...@hotmail.com wrote: Marcio Almada wrote in message news:caoshv+uho3ovs-beqmdjomz4sdwoyjn7znmcqmt8byynugq...@mail.gmail.com... Perhaps there should be a new rule which says that invoking a constructor with anything other than new or parent::__contruct() should be illegal, in which case this situation would generate an error. Now this would break a lot of code that $obj-__construct(); or $this-__construct(); And I've seen a lot of it. Surely, according to the principles of OO, a class constructor should ONLY be called when the class is constructed/instantiated into an object via the new verb? Google for class constructor and you will see all those links which say the same thing. Inheritance is also an OO principle, and typically a derived class’s constructor will call the parent’s. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Marcio Almada wrote in message news:caoshv+uho3ovs-beqmdjomz4sdwoyjn7znmcqmt8byynugq...@mail.gmail.com... Perhaps there should be a new rule which says that invoking a constructor with anything other than new or parent::__contruct() should be illegal, in which case this situation would generate an error. Now this would break a lot of code that $obj-__construct(); or $this-__construct(); And I've seen a lot of it. Surely, according to the principles of OO, a class constructor should ONLY be called when the class is constructed/instantiated into an object via the new verb? Google for class constructor and you will see all those links which say the same thing. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Tony Marston wrote on 19/01/2015 10:37: Rowan Collins wrote in message news:calkijkr3os6ta55rjlq61o1+on-s3j8xfzmhjvqfxozlzwt...@mail.gmail.com... On 18 January 2015 at 12:23, Tony Marston tonymars...@hotmail.com wrote: Rowan Collins wrote in message news:54baba93.9070...@gmail.com... This problem is partly solved in the RFC for Default Constructors (see https://wiki.php.net/rfc/default_ctor). If this were extended to cope with PHP 4 style constructors as well then all the problems would be solved. Then there would be no need to remove PHP 4 constructors at all. That's a good example of supporting old features adding complexity. And adding new features does not also increase complexity? Where did I say anything to the contrary? You're right, it could solve this problem, at the expense of extra code, with extra possibility of bugs. Adding new features also comes with the expense of extra code, extra complexity, and extra possibility of bugs. I actually look at the notes for each new release and I regularly see fixes to recently added features. Yes, complexity is a necessary evil. That doesn't mean we should give up trying to control the complexity. All compilers are complex beasts - that is the nature of compilers. If you cannot handle that complexity you shouldn't be working on a compiler. Saying that something is complex in no way justifies making it more complex; arguably, quite the opposite: compilers (and runtime engines) are complex enough at the best of times, so features which add to that complexity should be carefully evaluated New features add to the complexity more than old features. Maybe. Also, old features add to the complexity *of* new features, because every interaction between features has to be considered. None of which changes my point, which was simply that supporting old features adds some complexity, and removing that complexity can be a good thing in itself. to avoid the whole thing becoming an unmaintainable mess. Surely the core developers are competent enough to understand the necessity for structured code? If they followed all the best practices that exist on the web then how can they possibly produce code which can be described as a mess? Sure, and some of those best practices involve refactoring your code to have fewer edge cases where possible. Unfortunately, people may be relying on those edge cases, so a compromise has to be reached. snip Removing long-standing features for no good reason (and a change in style is never a good reason) does nothing more than frustrate all those 240 million website owners who find that their existing applications will no longer run. This is the primary reason why there is a slow adoption rate for each new release. If you stop breaking the language then the adoption rate will be quicker. I'm not sure why you've replied with a well-worn argument about no good reason to an e-mail whose sole purpose was pointing out a good reason. You may think my reason is not valid, but that doesn't make this paragraph remotely relevant or insightful. The only good reason given is that developers should no longer be using them. No, that is not the only reason given. This entire sub-thread is me giving another reason. It may not be a good enough reason, but it is a completely separate reason. Rather than simply assuming that people have no reason for something, why not ask what their reasons are *and listen to the answer*. BC breaks should only be allowed for bug fixes or security issues and never to enforce a new style over an older style. There are no problems with PHP 4 style constructors which could not be solved with an extension to https://wiki.php.net/rfc/default_ctor. The removal of PHP constructors would, however, cause problems in all those applications which use them, and this in turn would slow down the adoption of the new release. All you would be doing is solving a very minor problem for yourselves but creating a huge problem for your customers, all those 240 million websites which run PHP applications. Such a total disregard for customer satisfaction would not be tolerated in any other industry, or in many other segments of the software industry, so dismissing this argument as irrelevant shows that you haven't a clue about customer relations. You've said all this before. I understand. I agree that it should be taken into account. I don't think it's the whole story. Deprecating a feature or raising an E_STRICT doesn't, of course, reduce this complexity by itself - indeed, it slightly increases it - but it paves the way for a future version to decide that this feature is no longer supported, and can be removed in order to improve the rest of the engine. So, you are quite right to highlight the costs of doing this, and they may well outweigh the benefits in this case. However, you are wrong to assume that the only benefit to be
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Rowan Collins wrote in message news:54bd240a.7050...@gmail.com... Tony Marston wrote on 19/01/2015 15:01: The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. I am not ignoring the grievances, and have repeatedly said that I am not sure whether or not the change is justified in this case. You, however, are ignoring the benefits, and have repeatedly used phrasing that implies that you do not think they exist, right underneath my messages explaining what they are. There may be a small benefit to the core developers, but a huge negative benefit (i.e. problem) to the rest of the PHP community. When you identify something that benefits both the core developers and their customers I might be more inclined to listen. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Am 19.01.2015 um 17:42 schrieb Tony Marston: has already been pointed out that there are a large number of PEAR libraries which were written with PHP 4 constructors and have never been updated. So? If that code is still valuable to people they will update it. Or rather would have updated it ages ago. If not, then not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 19/01/15 16:45, Sebastian Bergmann wrote: has already been pointed out that there are a large number of PEAR libraries which were written with PHP 4 constructors and have never been updated. So? If that code is still valuable to people they will update it. Or rather would have updated it ages ago. If not, then not. Well I had to create my own port of PEAR that was e_strict safe, and this is another example of why the published code has NOT been updated ... because up until now with e_strict switched off ... it worked. I had supplied patches to update the distributed code, but they were never accepted ... so I just use them myself. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Andrey Andreev wrote in message news:CAPhkiZz=gYDbHngV+gHhTgW415_KxoCU-31OiW=dxPkPg=t...@mail.gmail.com... Hi, On Mon, Jan 19, 2015 at 5:01 PM, Tony Marston tonymars...@hotmail.com wrote: But the only benefits with the removal of old features is a smaller code base for the core developers. The only benefit which is experienced in userland is that applications which have run for over a decade suddenly stop working. Ah, so you admit there may be benefits? Again, I do not say that those benefits are definitely enough to justify the change in this case, but they are real, and I would like you to stop dismissing them. There is a big difference if a BC break which causes a minor benefit to the core developers also causes a major headache to the millions of developers who are the customers, the people who use the language to develop applications. The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. You continue doing exactly what you were asked not to. If I wish to complain I don't need to ask your permission. I also have the right to respond to every post which argues against my opinion. It's not just a minor benefit to the core developers. It's an extremely unpopular feature Unpopular means that people want to see it removed just because they don't like it. that often leads to debugging nightmares even for users with enough experience to take on senior development roles. Ignorance about how PHP works is no excuse. I believe that RTFM is the standard response in such situations. PHP 4 style coding is just unknown to the majority of users today and But not for those users who started developing with PHP before version 5 became mainstream. Your attitude seems to be Let's ignore those boring old farts who made the language what it is today and instead start pandering to a bunch of ignorant newbies. most people assume that it is no longer supported Then most people assumed wrongly. Why should one section of the PHP community be made to suffer because of a wrong assumption made by another part of the community? (or rather, that it was never supported, because they don't even know it existed). Just because a bunch of newbies didn't realise that a feature existed is no reason to remove that feature. There are functions in the language that I don't use and have no desire to use, but do you see me advocating for their removal? You're obviously an exception to that, and you might argue that somebody's lack of knowledge isn't an excuse to break all of your code, but please stop arguing that a handful of core PHP developers decided to drop a feature for their own benefit alone. That is simply not true. What benefit will there be to the PHP community outside of the core developers? Applications which don't use PHP 4 constructors will not notice a difference, but those which do will break. Where is the benefit in that? Also, I haven't seen PHP4 style constructors used in years and you're making it sound like every PHP application on the internet uses them - very far from it. Just because you haven't seen any does not mean that they don't exist. It has already been pointed out that there are a large number of PEAR libraries which were written with PHP 4 constructors and have never been updated. That being said, it is still a major BC issue and unfortunately we're not going to have PHP 5.7 where it could've been deprecated, so I guess being stuck with this feature (but deprecated) in PHP7 might be the wiser choice. Cheers, Andrey. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston tonymars...@hotmail.com wrote: Ah, so you admit there may be benefits? Again, I do not say that those benefits are definitely enough to justify the change in this case, but they are real, and I would like you to stop dismissing them. There is a big difference if a BC break which causes a minor benefit to the core developers also causes a major headache to the millions of developers who are the customers, the people who use the language to develop applications. The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. You continue doing exactly what you were asked not to. If I wish to complain I don't need to ask your permission. I also have the right to respond to every post which argues against my opinion. Somebody asked you simply to not dismiss their arguments, and you did exactly the opposite while quoting them. That's just rude and ignorant, and it will get you nowhere. If you want others to listen to your POV, you should start doing the same. This list is not a customer complaints book, it's a place for discussions. It's not just a minor benefit to the core developers. It's an extremely unpopular feature Unpopular means that people want to see it removed just because they don't like it. I don't appreciate you splitting my sentences into small pieces just to pick on them individually. I don't think I should explain you how combining words to form a meaning works. that often leads to debugging nightmares even for users with enough experience to take on senior development roles. Ignorance about how PHP works is no excuse. I believe that RTFM is the standard response in such situations. Talk about ignorance ... you've ignored the new style of coding for a decade and don't want to be bothered to adapt to it for another one. TFM clearly favors __construct(), and it does it for a reason. No matter the cause, if the feature causes issues for the majority of PHP developers, you can't just give them the finger because you don't want to spend a few hours renaming Foo::foo() to Foo::__construct(). Arguing about BC breaks is one thing, but don't excuse your own ignorance with others' lack of knowledge, when they've clearly been driven into that. PHP 4 style coding is just unknown to the majority of users today and But not for those users who started developing with PHP before version 5 became mainstream. Your attitude seems to be Let's ignore those boring old farts who made the language what it is today and instead start pandering to a bunch of ignorant newbies. Oh, right ... cause pandering to the ignorant old farts is better than pandering to the ignorant newbies. Neither is better, of course. However, it's not me who suggested anything about pandering to a certain group, and you're in the minority, so you probably don't want to go there - being born earlier doesn't give you the advantage. most people assume that it is no longer supported Then most people assumed wrongly. Why should one section of the PHP community be made to suffer because of a wrong assumption made by another part of the community? Again, you're putting this out of context. (or rather, that it was never supported, because they don't even know it existed). Just because a bunch of newbies didn't realise that a feature existed is no reason to remove that feature. There are functions in the language that I don't use and have no desire to use, but do you see me advocating for their removal? You would be, if they were causing you problems. It's 2015 and we're not talking about just a bunch of newbies. There are framework developers, evangelists, even core developers who would guess that this feature no longer exists. Nobody in the past decade has been taught to use the PHP4-style constructors. And that means that virtually all of the people who got into PHP programming during that period (and are aware of the feature) have learned it through spending hours of debugging because they wrote a Foo::foo() function. You're obviously an exception to that, and you might argue that somebody's lack of knowledge isn't an excuse to break all of your code, but please stop arguing that a handful of core PHP developers decided to drop a feature for their own benefit alone. That is simply not true. What benefit will there be to the PHP community outside of the core developers? Applications which don't use PHP 4 constructors will not notice a difference, but those which do will break. Where is the benefit in that? You're talking about complete, already running applications and completely ignoring the development process itself. It's kind of ironic that you're doing that because you don't want to spend time for development. Also, I haven't seen PHP4 style constructors used in years and you're making it sound like every PHP application on the internet uses them - very far from it.
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Tony Marston wrote on 19/01/2015 16:24: Rowan Collins wrote in message news:54bd240a.7050...@gmail.com... Tony Marston wrote on 19/01/2015 15:01: The aim should be to eliminate customer grievances as much as possible and not to simply ignore them. I am not ignoring the grievances, and have repeatedly said that I am not sure whether or not the change is justified in this case. You, however, are ignoring the benefits, and have repeatedly used phrasing that implies that you do not think they exist, right underneath my messages explaining what they are. There may be a small benefit to the core developers, but a huge negative benefit (i.e. problem) to the rest of the PHP community. When you identify something that benefits both the core developers and their customers I might be more inclined to listen. Anything that benefits the core developers in their task of maintaining and improving the core automatically benefits users, because the core is improved. The idea that the two interests are distinct, or even opposed to each other, is disingenuous to the people who volunteer their time in an honest effort to make PHP better for everyone. I'm going to duck out of this thread, now, because we're going round in circles, and if you want to know my opinion on the matter, you can read through the parts you ignored earlier. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Levi Morrison wrote in message news:cafmt4nopoeohga+uorsjrxosrh4k3eid96-jmmoqghct8uj...@mail.gmail.com... On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth tr...@proposaltech.com wrote: On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote: snip According to the PHP.net documentation on E_STRICT(http://php.net/manual/en/migrating5.errorrep.php): When enabled, messages will be issued to warn you about code usage which is deprecated or which may not be future-proof. By very definition E_STRICT warns about this kind of thing. They've been there for *more than ten years*. But only when you use both PHP 4 and PHP 5 constructors at the same time. If a class uses ONLY the PHP 4 constructor then no message is generated at all. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Rowan Collins wrote in message news:54baba93.9070...@gmail.com... On 17/01/2015 18:33, Todd Ruth wrote: As already mentioned I think as an end result we shouldn't have two ways to define constructors. Given that PHP already prefers the new-style constructors I've proposed that we work towards dropping the old-style, it's just down to a matter of how. I've been following these threads for about 10 years and beg that php internals continues to live and let live. There have been many, many threads over the years from what I would call (with obvious bias) OO fundamentalists. They seem to be at war with code that is bad form. This is an argument that comes up a lot, and it has some merit, sometimes. I don't think using __construct over named-method for constructors really has anything to do with OOP fundamentalism; it was a design change to make certain things simpler (like parent::__construct), This problem is partly solved in the RFC for Default Constructors (see https://wiki.php.net/rfc/default_ctor). If this were extended to cope with PHP 4 style constructors as well then all the problems would be solved. Then there would be no need to remove PHP 4 constructors at all. and more consistent (all reserved magic methods begin with __, so any method not beginning with that is safe to use however you like). In the global cost/benefit analysis I don't see that the benefits of purifying OO outweigh the costs. Not everything is a matter of code style - supporting legacy features comes at a cost in complexity, All compilers are complex beasts - that is the nature of compilers. If you cannot handle that complexity you shouldn't be working on a compiler. and sometimes even performance. Whenever new features are added - such as the ability to call parent::__construct when the parent doesn't declare a constructor explicitly - decisions have to be made on how they interact with old features - such as PHP4-style constructors. And simply by having an accumulation of old features, the codebase is larger, harder to understand, harder to change, and has more surface area for bugs. Removing long-standing features for no good reason (and a change in style is never a good reason) does nothing more than frustrate all those 240 million website owners who find that their existing applications will no longer run. This is the primary reason why there is a slow adoption rate for each new release. If you stop breaking the language then the adoption rate will be quicker. Deprecating a feature or raising an E_STRICT doesn't, of course, reduce this complexity by itself - indeed, it slightly increases it - but it paves the way for a future version to decide that this feature is no longer supported, and can be removed in order to improve the rest of the engine. So, you are quite right to highlight the costs of doing this, and they may well outweigh the benefits in this case. However, you are wrong to assume that the only benefit to be weighed is purifying OO. Yet the reasons I have seen for removing an existing feature are rarely to fix a problem but to make the language cleaner or more consistent. What this means in reality is PHP would be cleaner if it didn't contain all those features that I don't like and I don't use, and I don't want anybody else to use them either. Regards, -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Andrea Faulds wrote in message
news:d554c8b8-0bfb-44f7-b23e-8bfc12ae2...@ajf.me...
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins rowan.coll...@gmail.com wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
snip
I don't think using __construct over named-method for constructors really
has anything to do with OOP fundamentalism; it was a design change to
make certain things simpler (like parent::__construct), and more
consistent (all reserved magic methods begin with __, so any method not
beginning with that is safe to use however you like).
To add on to what you said, there’s also a quite important benefit that
__construct is a lot more obvious in what it does.
Looking at the following code:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function foo() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
It’s not easy to spot the constructor at a glance, and it’s very easy to
miss.
Compare that to the following:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function __construct() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
Far more obvious.
If a developer cannot read valid code then it is a developer problem. It is
not up to the language to dictate style - it provides the functions and
features while style and readability are the sole responsibility of the
individual developer.
This actually tripped me up on more than one occasion when updating tests
broken by the removal of PHP 4 constructors in php-src.
Perhaps this issue can be solved by the RFC on Default Constructors? See
https://wiki.php.net/rfc/default_ctor
Sure, the constructor should probably be the first method, but *even if it
is* it’s still nowhere near as obvious in PHP 4 style.
Similarly, what does the following do?
$this-foo();
It looks like a normal method call, and it is in a sense. But if you’re in
Bar and inheriting from Foo, that’s a call to the parent class’s
constructor!
Perhaps there should be a new rule which says that invoking a constructor
with anything other than new or parent::__contruct() should be illegal,
in which case this situation would generate an error.
The following is much more obvious:
parent::__construct();
I think it’s pretty clear why we changed to PHP5-style constructors. They’re
just a lot more recognisable. :)
--
Andrea Faulds
http://ajf.me/
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 18 January 2015 at 12:23, Tony Marston tonymars...@hotmail.com wrote: Rowan Collins wrote in message news:54baba93.9070...@gmail.com... On 17/01/2015 18:33, Todd Ruth wrote: As already mentioned I think as an end result we shouldn't have two ways to define constructors. Given that PHP already prefers the new-style constructors I've proposed that we work towards dropping the old-style, it's just down to a matter of how. I've been following these threads for about 10 years and beg that php internals continues to live and let live. There have been many, many threads over the years from what I would call (with obvious bias) OO fundamentalists. They seem to be at war with code that is bad form. This is an argument that comes up a lot, and it has some merit, sometimes. I don't think using __construct over named-method for constructors really has anything to do with OOP fundamentalism; it was a design change to make certain things simpler (like parent::__construct), This problem is partly solved in the RFC for Default Constructors (see https://wiki.php.net/rfc/default_ctor). If this were extended to cope with PHP 4 style constructors as well then all the problems would be solved. Then there would be no need to remove PHP 4 constructors at all. That's a good example of supporting old features adding complexity. You're right, it could solve this problem, at the expense of extra code, with extra possibility of bugs. and more consistent (all reserved magic methods begin with __, so any method not beginning with that is safe to use however you like). In the global cost/benefit analysis I don't see that the benefits of purifying OO outweigh the costs. Not everything is a matter of code style - supporting legacy features comes at a cost in complexity, All compilers are complex beasts - that is the nature of compilers. If you cannot handle that complexity you shouldn't be working on a compiler. Saying that something is complex in no way justifies making it more complex; arguably, quite the opposite: compilers (and runtime engines) are complex enough at the best of times, so features which add to that complexity should be carefully evaluated to avoid the whole thing becoming an unmaintainable mess. and sometimes even performance. Whenever new features are added - such as the ability to call parent::__construct when the parent doesn't declare a constructor explicitly - decisions have to be made on how they interact with old features - such as PHP4-style constructors. And simply by having an accumulation of old features, the codebase is larger, harder to understand, harder to change, and has more surface area for bugs. Removing long-standing features for no good reason (and a change in style is never a good reason) does nothing more than frustrate all those 240 million website owners who find that their existing applications will no longer run. This is the primary reason why there is a slow adoption rate for each new release. If you stop breaking the language then the adoption rate will be quicker. I'm not sure why you've replied with a well-worn argument about no good reason to an e-mail whose sole purpose was pointing out a good reason. You may think my reason is not valid, but that doesn't make this paragraph remotely relevant or insightful. Deprecating a feature or raising an E_STRICT doesn't, of course, reduce this complexity by itself - indeed, it slightly increases it - but it paves the way for a future version to decide that this feature is no longer supported, and can be removed in order to improve the rest of the engine. So, you are quite right to highlight the costs of doing this, and they may well outweigh the benefits in this case. However, you are wrong to assume that the only benefit to be weighed is purifying OO. Yet the reasons I have seen for removing an existing feature are rarely to fix a problem but to make the language cleaner or more consistent. What this means in reality is PHP would be cleaner if it didn't contain all those features that I don't like and I don't use, and I don't want anybody else to use them either. Again, you have opted to ignore my point rather than respond to it. I am not saying there is definitely sufficient justification to remove this particular feature, but the idea that PHP could simply continue forever to support every feature it has ever had, with no cost to anyone, and that therefore anyone wanting to remove things is some kind of selfish dictator is patently false. Those proposing changes should certainly justify the benefits, but those opposing should not simply pretend that those benefits cannot exist. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Perhaps there should be a new rule which says that invoking a constructor
with anything other than new or parent::__contruct()
should be illegal, in which case this situation would generate an error.
Now this would break a lot of code that $obj-__construct(); or
$this-__construct(); And I've seen a lot of it.
2015-01-18 9:33 GMT-03:00 Tony Marston tonymars...@hotmail.com:
Andrea Faulds wrote in message
news:d554c8b8-0bfb-44f7-b23e-8bfc12ae2...@ajf.me...
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins rowan.coll...@gmail.com wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
snip
I don't think using __construct over named-method for constructors really
has anything to do with OOP fundamentalism; it was a design change to make
certain things simpler (like parent::__construct), and more consistent (all
reserved magic methods begin with __, so any method not beginning with that
is safe to use however you like).
To add on to what you said, there’s also a quite important benefit that
__construct is a lot more obvious in what it does.
Looking at the following code:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function foo() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
It’s not easy to spot the constructor at a glance, and it’s very easy to
miss.
Compare that to the following:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function __construct() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
Far more obvious.
If a developer cannot read valid code then it is a developer problem. It is
not up to the language to dictate style - it provides the functions and
features while style and readability are the sole responsibility of the
individual developer.
This actually tripped me up on more than one occasion when updating tests
broken by the removal of PHP 4 constructors in php-src.
Perhaps this issue can be solved by the RFC on Default Constructors? See
https://wiki.php.net/rfc/default_ctor
Sure, the constructor should probably be the first method, but *even if it
is* it’s still nowhere near as obvious in PHP 4 style.
Similarly, what does the following do?
$this-foo();
It looks like a normal method call, and it is in a sense. But if you’re in
Bar and inheriting from Foo, that’s a call to the parent class’s
constructor!
Perhaps there should be a new rule which says that invoking a constructor
with anything other than new or parent::__contruct() should be illegal,
in which case this situation would generate an error.
The following is much more obvious:
parent::__construct();
I think it’s pretty clear why we changed to PHP5-style constructors.
They’re just a lot more recognisable. :)
--
Andrea Faulds
http://ajf.me/
--
Tony Marston
--
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] [RFC] Remove PHP 4 Constructors
Hi, Please don't construe the willingness to add E_STRICTs with agreement that such code should be forcibly eliminated. If there were a fully automated tool to bring code into compliance, I would feel a lot better about such changes, but even then, many of us would be applying that tool to third-party code that has been lying around for a decade untouched, and that's scary. such a tool has been proposed and even without it, it's a matter of (tedious) search replace; I suppose my opinion on these things is formed by my life experience with these issues and since I don't doubt we all mean well, I guess the OO purists probably are approaching this from different life experiences. Here is where I'm coming from: This is not about purism. Leaving support for PHP4 constructors in the code means this code must be maintained for every core change that affects constructors. To this day, we still don't use namespaces or exceptions. No part of PHP forces you to write your code this way. You can still work with Error classes or Error return values and so on. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Levi Morrison wrote in message
news:CAFMT4NrH+=6B4=kvyrmw1oc0n-_onndjawk0xzcxdvnv_pn...@mail.gmail.com...
We are talking about something deprecated since 10 years, about the 1st
major release in a decade, something we will use for the next 12-14
years.
That is the point - PHP 4 constructors have NOT been marked as deprecated
in
the manual, and they produce no warnings at runtime.
If they have not been marked as deprecated then you cannot suddenly
remove
them.
Warning: a long response with code snippets/
See this code (http://3v4l.org/ViPpb):
class Test {
function test() {
echo __METHOD__, PHP_EOL;
}
function __construct() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Note that there is an E_STRICT generated for having both constructor
types in all versions of PHP 5 and that `__construct` is actually used
as the constructor.
An error is only generated if I use BOTH types of constructor in the same
class. If I use the PHP 4 constructor on its own then no error is generated.
snip
To me this clearly indicates three things:
1. Having both forms of constructors is bad form (hence the E_STRICT)
I agree.
2. When both are present the new-style __construct is used over the
old-style PHP 4 constructor, meaning the language prefers
__constructor.
I agree.
3. Old-style constructors don't exist in namespaces. Notably this
was a conscious choice as evidenced by behavior that existed in PHP
5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code.
The fact that namespaces completely ignore a non-deprecated feature of the
language is a fault in the namespace implementation.
This is the behavior of shipped, stable versions of PHP. I think it's
a bit illogical to conclude that just because there aren't any
E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are
fully supported.
My point is that if all constructors are PHP 4 style only then no error is
generated at all. It is therefore wrong to say that PHP 4 constructors have
been deprecated. The manual certainly does NOT say that they are deprecated.
That leaves us realistically with four options:
1. Bring full support for PHP 4 constructors
Good idea. Perhaps the RFC on default constructors should be extended to
cover both styles of constructor, in which case a call to
parent::__construct() will never fail regardless of whether a constructor
actually exists or not, or whether it is and old or new style constructor.
An existing feature should not be removed from the language unless it causes
a problem as its removal will not solve any problem and therefore cannot be
justified. If there is a problem then here are two choices:
(a) Fix the problem.
(b) Remove the feature.
Option (a) may involve a bit more work for the core developers, but option
(b) will always cause massive amounts of pain in userland and will slow down
the adoption rate for that release.
Any core developer who chooses option (b) is admitting two things:
(a) They don't know how to fix the problem.
(b) They don't care how much pain they cause for their customers all those
developers who create applications which run on over 240 million websites.
2. Emit E_DEPRECATED when PHP 4 constructors are used
3. Drop support for PHP 4 constructors so they are just normal
methods, just as they are in namespaces
4. Maintain current behavior.
As already mentioned I think as an end result we shouldn't have two
ways to define constructors.
Then why was a different method introduced in PHP 5 in the first place?
There was nothing wrong with PHP 4 constructors as they follow other
languages such as Java, C++ and C#, so they could never be described as
either wrong or inconsistent.
Given that PHP already prefers the
new-style constructors I've proposed that we work towards dropping the
old-style, it's just down to a matter of how.
Forcing your personal preferences on the rest of the PHP community will do
nothing but diminish your stature as a core developer in the eyes of those
members of the community who have different preferences. This is the
attitude of a small-minded dictator.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 17/01/15 05:54, Pierre Joye wrote: Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. Not much to say about it as it is a taste/yes/no thing. Let wait the required period and move to vote, I do not see much needs to argue in a circular way forever :) Switching code to __construct is on my 5.2 to 5.4 upgrade crib sheet. I thought because e_strict moans about it? But on a quick scan I can't find a reference other than NOT flagging a warning when different parameters are used. Obviously this modernise is useful anyway, but where does it fit in the error handling currently? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Stelian Mocanita wrote in message news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com... Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason. Completely agree, but you get once in N years a chance to do some cleanup on the language. If people expect no BC breaks on major versions, when is the time for the cleanup? It is one thing to remove functionality from the core if it a security issue or it causes bugs, but people's definitions of clean are many and varied, so using that as an excuse to break the language will not down well with those millions of website owners whose applications suddenly stop working after an upgrade. By clean it is obvious that you mean style as in don't do it like that, do it like this. It is not up to the core developers to dictate style on the rest of the programmer community - you provide the basic tools, and it is up to the individual programmer to decide what functions to use in order to solve the problem at hand. Programming style is the prerogative of the individual programmer, or a team of programmers, and should never be dictated by any outside agency. That's one thing. The other thing is that there's a flow in your logic. If you want the bug/security/performance fixes, it means you are already running latest stable and for some reason you completely ignored all of the deprecation warnings until now. I think we can both agree on this being a bit far-fetched. I am using PHP 5.6.4 with error_reporting=E_ALL and I am not seeing any messages regarding my use of PHP 4 constructors. They are also NOT marked as deprecated in the manual. If they are not marked as deprecated then you cannot suddenly remove them. Besides, what problem(s) would be solved by removing PHP 4 constructors? If there are no problems then removing them would not only NOT solve any problem it would actually create a HUGE problem for all those applications which still use them. Not to mention that all the old ctor fatal errors can be fixed with an automated scripts that replaces the old ctors with the new ones. Stelian -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote: Stelian Mocanita wrote in message news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com... Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason. Can wie stop using this argument pls? We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. 5.x will be maintained as well for the next 3 years (plus distros LTS). We do not break BC since quite some time too in minor releases. Cheers, Pierre
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote: Stelian Mocanita wrote in message news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com... Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason. Can wie stop using this argument pls? Not while it is a valid argument in the eyes of the millions of developers who use PHP We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. That is the point - PHP 4 constructors have NOT been marked as deprecated in the manual, and they produce no warnings at runtime. If they have not been marked as deprecated then you cannot suddenly remove them. 5.x will be maintained as well for the next 3 years (plus distros LTS). We do not break BC since quite some time too in minor releases. Good. Breaking BC for no good reason is never a good idea. Cheers, Pierre -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 16.01.2015 09:00, Matteo Beccati wrote: On 15/01/2015 22:16, Ralf Lang wrote: On 15.01.2015 21:35, Mike wrote: Wouldn't this one change render all code in PEAR as broken? No. Why not? PEAR uses PHP4-constructors almost everywhere. A lot of pear packages don't use custom constructors at all. But PEAR can be fixed, I guess. Along with application using/extending it. The process can be automated, but still there's quite some work to do. Yes, those parts worth fixing will and can be fixed. Other parts stay php4/5-only for use with legacy code. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi Pierre! On 17/01/15 08:02, Pierre Joye wrote: On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote: Stelian Mocanita wrote in message news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com... Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason. Can wie stop using this argument pls? We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. 5.x will be maintained as well for the next 3 years (plus distros LTS). We do not break BC since quite some time too in minor releases. Cheers, Pierre Wouldn't be better if we borrow things from Perl? I mean, we have an 'strict mode' (`use strict;` perhaps) where deprecated things doesn't work at all and they throw exceptions (such as the old PH4 constructors for instance). Cheers, -- César D. Rodas Open Source developer +595-983-161124 PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 17 January 2015 at 13:38, César Rodas ce...@rodas.me wrote: Hi Pierre! On 17/01/15 08:02, Pierre Joye wrote: On Jan 17, 2015 5:58 PM, Tony Marston tonymars...@hotmail.com wrote: Stelian Mocanita wrote in message news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com. .. Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason. Can wie stop using this argument pls? We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. 5.x will be maintained as well for the next 3 years (plus distros LTS). We do not break BC since quite some time too in minor releases. Cheers, Pierre Wouldn't be better if we borrow things from Perl? I mean, we have an 'strict mode' (`use strict;` perhaps) where deprecated things doesn't work at all and they throw exceptions (such as the old PH4 constructors for instance). In this case, I think that would actually be the worst of both worlds - support for PHP 4 constructors would still need to be maintained in core, with extra logic for handling the mode switch. Meanwhile, people using old code with old constructors would never turn strict mode on, and people who turn strict mode on are probably already well aware that they should be using __construct. Annoying though it would be to receive dozens of them, I think issuing an E_DEPRECATED notice when such constructors are defined is probably the best approach for now. It does once again make me want medically scoped error reporting, though (e.g. ignore E_DEPRECATED and E_NOTICE raised in this PEAR module which I am phasing out anyway) -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
We are talking about something deprecated since 10 years, about the 1st
major release in a decade, something we will use for the next 12-14 years.
That is the point - PHP 4 constructors have NOT been marked as deprecated in
the manual, and they produce no warnings at runtime.
If they have not been marked as deprecated then you cannot suddenly remove
them.
Warning: a long response with code snippets/
See this code (http://3v4l.org/ViPpb):
class Test {
function test() {
echo __METHOD__, PHP_EOL;
}
function __construct() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Note that there is an E_STRICT generated for having both constructor
types in all versions of PHP 5 and that `__construct` is actually used
as the constructor.
Now if you change the order of the definitions around (http://3v4l.org/BhPMm):
class Test {
function __construct() {
echo __METHOD__, PHP_EOL;
}
function test() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Note that `__construct` is still used and the E_STRICT is only
generated in PHP 5.0-5.3 (roughly; it's a bit more nuanced).
If you put a namespace at the top of the first example(http://3v4l.org/hWFnC):
namespace NS;
class Test {
function test() {
echo __METHOD__, PHP_EOL;
}
function __construct() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Then there are no warnings of any kind (since PHP 5.3.2), and
__construct is used as the constructor. The method test is just a
normal method.
To me this clearly indicates three things:
1. Having both forms of constructors is bad form (hence the E_STRICT)
2. When both are present the new-style __construct is used over the
old-style PHP 4 constructor, meaning the language prefers
__constructor.
3. Old-style constructors don't exist in namespaces. Notably this
was a conscious choice as evidenced by behavior that existed in PHP
5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code.
This is the behavior of shipped, stable versions of PHP. I think it's
a bit illogical to conclude that just because there aren't any
E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are
fully supported.
That leaves us realistically with four options:
1. Bring full support for PHP 4 constructors
2. Emit E_DEPRECATED when PHP 4 constructors are used
3. Drop support for PHP 4 constructors so they are just normal
methods, just as they are in namespaces
4. Maintain current behavior.
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP already prefers the
new-style constructors I've proposed that we work towards dropping the
old-style, it's just down to a matter of how.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote: We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. That is the point - PHP 4 constructors have NOT been marked as deprecated in the manual, and they produce no warnings at runtime. If they have not been marked as deprecated then you cannot suddenly remove them. Warning: a long response with code snippets/ [ Snipped examples of mixing constructor flavors / namespaces ] Then there are no warnings of any kind (since PHP 5.3.2), and __construct is used as the constructor. The method test is just a normal method. To me this clearly indicates three things: 1. Having both forms of constructors is bad form (hence the E_STRICT) 2. When both are present the new-style __construct is used over the old-style PHP 4 constructor, meaning the language prefers __constructor. 3. Old-style constructors don't exist in namespaces. Notably this was a conscious choice as evidenced by behavior that existed in PHP 5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code. This is the behavior of shipped, stable versions of PHP. I think it's a bit illogical to conclude that just because there aren't any E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are fully supported. That leaves us realistically with four options: 1. Bring full support for PHP 4 constructors 2. Emit E_DEPRECATED when PHP 4 constructors are used 3. Drop support for PHP 4 constructors so they are just normal methods, just as they are in namespaces 4. Maintain current behavior. As already mentioned I think as an end result we shouldn't have two ways to define constructors. Given that PHP already prefers the new-style constructors I've proposed that we work towards dropping the old-style, it's just down to a matter of how. I've been following these threads for about 10 years and beg that php internals continues to live and let live. There have been many, many threads over the years from what I would call (with obvious bias) OO fundamentalists. They seem to be at war with code that is bad form. Fortunately, most of their victories to date have been in the form of adding E_STRICTs. There seems to be a compromise in the community that we won't break people's code, but we'll let them know when they are using bad form code. I believe that's reasonable. Please don't construe the willingness to add E_STRICTs with agreement that such code should be forcibly eliminated. If there were a fully automated tool to bring code into compliance, I would feel a lot better about such changes, but even then, many of us would be applying that tool to third-party code that has been lying around for a decade untouched, and that's scary. I suppose my opinion on these things is formed by my life experience with these issues and since I don't doubt we all mean well, I guess the OO purists probably are approaching this from different life experiences. Here is where I'm coming from: I've been on my current project for over 10 years. We have always had a _very_ small software department. The code was originally developed in php4 style using using objects, but not following the purist OO conventions. We now have hundreds of thousands of lines of php. We've accumulated reliance on many libraries that were written in a variety of styles and generally we're just glad they work. I'm sure there is no active development on many (perhaps most) of them. To this day, we still don't use namespaces or exceptions. We still follow our conventions for prefixing everything to avoid name collisions. We don't have the resources to make major changes without clear benefits to our users. (For the record, when we do find an issue with php, we dig in and try to find a fix and submit it. We've fixed a couple of things. I know it is negligible compared to what most of the folks reading this do.) I don't know how common our situation is, but I'm sure there are others out there. In the global cost/benefit analysis I don't see that the benefits of purifying OO outweigh the costs. Thanks for listening! - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hey Rowan,
On 17 Jan 2015, at 19:40, Rowan Collins rowan.coll...@gmail.com wrote:
On 17/01/2015 18:33, Todd Ruth wrote:
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP already prefers the
new-style constructors I've proposed that we work towards dropping the
old-style, it's just down to a matter of how.
I've been following these threads for about 10 years and beg that php
internals continues to live and let live.
There have been many, many threads over the years from what I would call
(with obvious bias) OO fundamentalists. They seem to be at war with
code that is bad form.
This is an argument that comes up a lot, and it has some merit, sometimes.
I don't think using __construct over named-method for constructors really has
anything to do with OOP fundamentalism; it was a design change to make
certain things simpler (like parent::__construct), and more consistent (all
reserved magic methods begin with __, so any method not beginning with that
is safe to use however you like).
To add on to what you said, there’s also a quite important benefit that
__construct is a lot more obvious in what it does.
Looking at the following code:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function foo() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
It’s not easy to spot the constructor at a glance, and it’s very easy to miss.
Compare that to the following:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function __construct() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
Far more obvious. This actually tripped me up on more than one occasion when
updating tests broken by the removal of PHP 4 constructors in php-src. Sure,
the constructor should probably be the first method, but *even if it is* it’s
still nowhere near as obvious in PHP 4 style.
Similarly, what does the following do?
$this-foo();
It looks like a normal method call, and it is in a sense. But if you’re in Bar
and inheriting from Foo, that’s a call to the parent class’s constructor!
The following is much more obvious:
parent::__construct();
I think it’s pretty clear why we changed to PHP5-style constructors. They’re
just a lot more recognisable. :)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth tr...@proposaltech.com wrote: On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote: We are talking about something deprecated since 10 years, about the 1st major release in a decade, something we will use for the next 12-14 years. That is the point - PHP 4 constructors have NOT been marked as deprecated in the manual, and they produce no warnings at runtime. If they have not been marked as deprecated then you cannot suddenly remove them. Warning: a long response with code snippets/ [ Snipped examples of mixing constructor flavors / namespaces ] Then there are no warnings of any kind (since PHP 5.3.2), and __construct is used as the constructor. The method test is just a normal method. To me this clearly indicates three things: 1. Having both forms of constructors is bad form (hence the E_STRICT) 2. When both are present the new-style __construct is used over the old-style PHP 4 constructor, meaning the language prefers __constructor. 3. Old-style constructors don't exist in namespaces. Notably this was a conscious choice as evidenced by behavior that existed in PHP 5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code. This is the behavior of shipped, stable versions of PHP. I think it's a bit illogical to conclude that just because there aren't any E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are fully supported. That leaves us realistically with four options: 1. Bring full support for PHP 4 constructors 2. Emit E_DEPRECATED when PHP 4 constructors are used 3. Drop support for PHP 4 constructors so they are just normal methods, just as they are in namespaces 4. Maintain current behavior. As already mentioned I think as an end result we shouldn't have two ways to define constructors. Given that PHP already prefers the new-style constructors I've proposed that we work towards dropping the old-style, it's just down to a matter of how. I've been following these threads for about 10 years and beg that php internals continues to live and let live. There have been many, many threads over the years from what I would call (with obvious bias) OO fundamentalists. They seem to be at war with code that is bad form. Fortunately, most of their victories to date have been in the form of adding E_STRICTs. There seems to be a compromise in the community that we won't break people's code, but we'll let them know when they are using bad form code. I believe that's reasonable. Please don't construe the willingness to add E_STRICTs with agreement that such code should be forcibly eliminated. According to the PHP.net documentation on E_STRICT(http://php.net/manual/en/migrating5.errorrep.php): When enabled, messages will be issued to warn you about code usage which is deprecated or which may not be future-proof. By very definition E_STRICT warns about this kind of thing. They've been there for *more than ten years*. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 17/01/2015 18:33, Todd Ruth wrote: As already mentioned I think as an end result we shouldn't have two ways to define constructors. Given that PHP already prefers the new-style constructors I've proposed that we work towards dropping the old-style, it's just down to a matter of how. I've been following these threads for about 10 years and beg that php internals continues to live and let live. There have been many, many threads over the years from what I would call (with obvious bias) OO fundamentalists. They seem to be at war with code that is bad form. This is an argument that comes up a lot, and it has some merit, sometimes. I don't think using __construct over named-method for constructors really has anything to do with OOP fundamentalism; it was a design change to make certain things simpler (like parent::__construct), and more consistent (all reserved magic methods begin with __, so any method not beginning with that is safe to use however you like). In the global cost/benefit analysis I don't see that the benefits of purifying OO outweigh the costs. Not everything is a matter of code style - supporting legacy features comes at a cost in complexity, and sometimes even performance. Whenever new features are added - such as the ability to call parent::__construct when the parent doesn't declare a constructor explicitly - decisions have to be made on how they interact with old features - such as PHP4-style constructors. And simply by having an accumulation of old features, the codebase is larger, harder to understand, harder to change, and has more surface area for bugs. Deprecating a feature or raising an E_STRICT doesn't, of course, reduce this complexity by itself - indeed, it slightly increases it - but it paves the way for a future version to decide that this feature is no longer supported, and can be removed in order to improve the rest of the engine. So, you are quite right to highlight the costs of doing this, and they may well outweigh the benefits in this case. However, you are wrong to assume that the only benefit to be weighed is purifying OO. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 15/01/2015 22:16, Ralf Lang wrote: On 15.01.2015 21:35, Mike wrote: Wouldn't this one change render all code in PEAR as broken? No. Why not? PEAR uses PHP4-constructors almost everywhere. But PEAR can be fixed, I guess. Along with application using/extending it. The process can be automated, but still there's quite some work to do. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Thu, 15 Jan 2015, Levi Morrison wrote: On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote: Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Possibly. The reality of my position is that I am unhappy about our current constructor situation. Having `__construct` and only half-heartedly supporting old-style constructors for the next several years (maybe ten?) does not sound good at all. Removing one of the constructors is a nicer end product than fully supporting both, in my opinion, which is why I proposed dropping it. Instead of just dropping it, which would likely generate odd bugs, declaring an old style constructor should *tell* you it's no longer working- perhaps with as strong of an error as an E_COMPILE_ERROR—atleast for PHP 7. Just removing it support would, IMO, be silly. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Best, Stelian On Fri, Jan 16, 2015 at 12:28 PM, Derick Rethans der...@php.net wrote: On Thu, 15 Jan 2015, Levi Morrison wrote: On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote: Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Possibly. The reality of my position is that I am unhappy about our current constructor situation. Having `__construct` and only half-heartedly supporting old-style constructors for the next several years (maybe ten?) does not sound good at all. Removing one of the constructors is a nicer end product than fully supporting both, in my opinion, which is why I proposed dropping it. Instead of just dropping it, which would likely generate odd bugs, declaring an old style constructor should *tell* you it's no longer working- perhaps with as strong of an error as an E_COMPILE_ERROR—atleast for PHP 7. Just removing it support would, IMO, be silly. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi Stelian, Stelian Mocanita writes: Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. Best, Stelian Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. Upgrading to a new Major version is expected to require at least some checking and adaptation, so would require at least semi-active development status on the part of the project, IMHO. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Florian Margaine wrote on 16/01/2015 13:01: Hi Stelian, Stelian Mocanita writes: Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. Completely agree, but you get once in N years a chance to do some cleanup on the language. If people expect no BC breaks on major versions, when is the time for the cleanup? That's one thing. The other thing is that there's a flow in your logic. If you want the bug/security/performance fixes, it means you are already running latest stable and for some reason you completely ignored all of the deprecation warnings until now. I think we can both agree on this being a bit far-fetched. Not to mention that all the old ctor fatal errors can be fixed with an automated scripts that replaces the old ctors with the new ones. Stelian
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
hi, On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@php.net wrote: Dear Internals, I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. Not much to say about it as it is a taste/yes/no thing. Let wait the required period and move to vote, I do not see much needs to argue in a circular way forever :) 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] [RFC] Remove PHP 4 Constructors
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote: Hey Levi, Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Possibly. The reality of my position is that I am unhappy about our current constructor situation. Having `__construct` and only half-heartedly supporting old-style constructors for the next several years (maybe ten?) does not sound good at all. Removing one of the constructors is a nicer end product than fully supporting both, in my opinion, which is why I proposed dropping it. I was hoping that a deprecation notice in 5.7 would be sufficient along with other standard migration tools and documentation, but since we have decided to not release 5.7 perhaps a deprecation would be better. At the same time I'm not thrilled about the amount of deprecation notices that could be generated if this is really as common as people seem to make it. I generally don't see these older constructors, but it seems when people have them they have *a lot* of them. I was okay with this in a theoretical 5.7 release to ease migration because it had a fixed lifespan of one release cycle but in version 7 it will stay for the duration of all PHP 7 releases. What do you guys think? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hey Levi, Upon further thought, I’m not super-enthusiastic about this. As has been pointed out, it’s a pretty serious BC break, whether code can be automatically updated or not. PHP 4 constructors may be obsolete, but an awful lot of code uses them. A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Thoughts? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hey Levi, On 15 Jan 2015, at 17:16, Levi Morrison le...@php.net wrote: On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote: A better solution, IMO, might be simply to add a deprecation notice. This would make it obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage migration away from them, but wouldn’t prevent existing code from working. Possibly. The reality of my position is that I am unhappy about our current constructor situation. Having `__construct` and only half-heartedly supporting old-style constructors for the next several years (maybe ten?) does not sound good at all. I agree, it doesn’t. Unfortunately, I’m not sure if we have much choice here. Removing one of the constructors is a nicer end product than fully supporting both, in my opinion, which is why I proposed dropping it. I was hoping that a deprecation notice in 5.7 would be sufficient along with other standard migration tools and documentation, but since we have decided to not release 5.7 perhaps a deprecation would be better. At the same time I'm not thrilled about the amount of deprecation notices that could be generated if this is really as common as people seem to make it. I generally don't see these older constructors, but it seems when people have them they have *a lot* of them. Yeah, I’m wondering about that. I imagine that a single request would probably result in a massive spew of E_DEPRECATEDs, and that’s not good. :/ I was okay with this in a theoretical 5.7 release to ease migration because it had a fixed lifespan of one release cycle but in version 7 it will stay for the duration of all PHP 7 releases. What do you guys think? I wonder if we could hopefully get rid of them for PHP 8 or something, since it’s deprecated… but then, if we don’t get rid of them now, we might never. I’m not sure, really. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi everyone, I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. I still think this (and other) BC breaks should be avoided if we want to maximize PHP7 adoption, but I've started working on this: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970 which is a patch to php-cs-fixer that would be helpful to ease my (and other's) pain in case the RFC passes. I've tried using Andrea's own work and nikita's php-parser and good results quickly, but ended up switching due to the lack of whitespace support. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Wouldn't this one change render all code in PEAR as broken? Is the gain really worth it? I understand PEAR is basically dead anyways, but for better or worse there is still a boat load of code that is being used from it (much of which lacks decent alternatives), and as other people mentioned such a BC break is likely to add years to the adoption of PHP7, which doesn't do anyone any good. On 01/15/2015 08:39 AM, Matteo Beccati wrote: Hi everyone, I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. I still think this (and other) BC breaks should be avoided if we want to maximize PHP7 adoption, but I've started working on this: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970 which is a patch to php-cs-fixer that would be helpful to ease my (and other's) pain in case the RFC passes. I've tried using Andrea's own work and nikita's php-parser and good results quickly, but ended up switching due to the lack of whitespace support. Cheers -- Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote: On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote: On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote: On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc/remove_php4_constructors Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have missed this) If so, then the timeline is perfect, one full release to deprecate, and a major-version bump to remove on. Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC pases, I was going to write up the let's do a 5.7 RFC if nobody else did. Yes, we did. And we decided not to have it because it will impact php7 timeline. That e-mail was almost two months ago. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Fri, Jan 16, 2015 at 8:14 AM, Adam Harvey ahar...@php.net wrote: On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote: On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote: On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote: On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc/remove_php4_constructors Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have missed this) If so, then the timeline is perfect, one full release to deprecate, and a major-version bump to remove on. Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC pases, I was going to write up the let's do a 5.7 RFC if nobody else did. Yes, we did. And we decided not to have it because it will impact php7 timeline. That e-mail was almost two months ago. :) lol he just showed up on top today, ah joy :) -- 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] [RFC] Remove PHP 4 Constructors
On 15.01.2015 21:35, Mike wrote: Wouldn't this one change render all code in PEAR as broken? No. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote: On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote: On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc/remove_php4_constructors Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have missed this) If so, then the timeline is perfect, one full release to deprecate, and a major-version bump to remove on. Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC pases, I was going to write up the let's do a 5.7 RFC if nobody else did. Yes, we did. And we decided not to have it because it will impact php7 timeline. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Fri, Nov 21, 2014 at 11:20 AM, Levi Morrison le...@php.net wrote: BTW, old constructor has problem with traits (is this mentioned already?) http://3v4l.org/KZKXo I suppose nobody is using this side effect in production code, but there would be number of users who are confused by this behavior. If I remember the source code correctly, this should be considered a bug. I will definitely look into this, regardless of the outcome of this RFC. It turns out I was incorrect; based on the code and the phpt tests I would not say this is a bug. However, traits do check for colliding constructors and emit a fatal error when having both a method named after the class and a __construct method: http://3v4l.org/YHAtA. Note that it doesn't matter who declares the old and new style constructors: http://3v4l.org/ZOeoY. When defining only the same style of constructor in both there is no error: http://3v4l.org/H1jG1 and http://3v4l.org/m5D7p. I will lift this restriction in the RFC for both PHP 5.7 and 7 and update the implementation when I can. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc/remove_php4_constructors Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have missed this) If so, then the timeline is perfect, one full release to deprecate, and a major-version bump to remove on. Two thumbs up, would upvote again. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote: On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc/remove_php4_constructors Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have missed this) If so, then the timeline is perfect, one full release to deprecate, and a major-version bump to remove on. Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC pases, I was going to write up the let's do a 5.7 RFC if nobody else did. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 20/11/14 21:29, Rowan Collins wrote: The problem is that the constructor is part of the public API (for inheritance purposes) so the required refactoring is not necessarily isolated to one project, or even doable by one developer. The maintainer of the library must first release a version with the new constructors in place, and the consumer of the library must then audit their code for anything relying on the old constructor. Supporting various combinations of PHP 5/7, old/new lib, and old/new consumer code is then messy at best. I agree that it's perfectly doable, but it's not as easy to migrate as, say, a syntax change. I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Lester Caine wrote on 21/11/2014 09:49: I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! To reply with a broken record of my own: E_STRICT does not indicate code that will break in a future version. Hiding E_STRICT notices will have absolutely no detrimental effect on your code, now or in the future. It is up to you if you want to improve the code by following the hints, or ignore them because the code works fine. So, no this is not at all similar to the problem of E_STRICT, because that problem is not real. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 21/11/14 11:31, Rowan Collins wrote: I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! To reply with a broken record of my own: E_STRICT does not indicate code that will break in a future version. Hiding E_STRICT notices will have absolutely no detrimental effect on your code, now or in the future. It is up to you if you want to improve the code by following the hints, or ignore them because the code works fine. So, no this is not at all similar to the problem of E_STRICT, because that problem is not real. So everything that currently requires e_strict disabled to allow it to work will continue to work in PHP7? Including the parts that have now been marked for removal since being deprecated since PHP5.3? In practice ... NO the code does not work fine UNLESS you ensure that all of the infrastructure is still using old versions of libraries. And even then we still get white screen responses with changes of PHP versions. My point is that on one hand people are COMPLAINING that code such as PHP 4 Constructors is not being updated and then ALSO claiming that we don't need to ... PLEASE can we have a level playing field to code to! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Zitat von Lester Caine les...@lsces.co.uk: On 21/11/14 11:31, Rowan Collins wrote: I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! To reply with a broken record of my own: E_STRICT does not indicate code that will break in a future version. Hiding E_STRICT notices will have absolutely no detrimental effect on your code, now or in the future. It is up to you if you want to improve the code by following the hints, or ignore them because the code works fine. So, no this is not at all similar to the problem of E_STRICT, because that problem is not real. So everything that currently requires e_strict disabled to allow it to work will continue to work in PHP7? Including the parts that have now been marked for removal since being deprecated since PHP5.3? You confuse E_STRICT with E_DEPRECATED. Without raising E_DEPRECATED in an earlier minor PHP release, a feature/construct cannot be removed from PHP. In practice ... NO the code does not work fine UNLESS you ensure that all of the infrastructure is still using old versions of libraries. And even then we still get white screen responses with changes of PHP versions. My point is that on one hand people are COMPLAINING that code such as PHP 4 Constructors is not being updated and then ALSO claiming that we don't need to ... PLEASE can we have a level playing field to code to! I still don't get get what problem this RFC is actually going to solve? I don't see a problem. Yes, PHP4 constructors are are old and should no longer be used. But there is no problem still supporting them. Raise an E_DEPRECATED for those, and be done with it. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi, I still don't get get what problem this RFC is actually going to solve? I don't see a problem. Yes, PHP4 constructors are are old and should no longer be used. But there is no problem still supporting them. Raise an E_DEPRECATED for those, and be done with it. +1 I can accept BC-breaks if there's a good reason, but this one seems a little weak. For reference 1/3 of the 4500+ php files in the project I work on every day still uses PHP4 constructors. And one third of them is within the bundled PEAR libraries. I'm not saying it is quality code, but it's a dinosaur open source project... I believe that many other historical open source projects are in the same boat. All the (unpaid) time that the team(s) would need to waste on this could be better spent elsewhere. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 21/11/14 12:36, Jan Schneider wrote: Zitat von Lester Caine les...@lsces.co.uk: On 21/11/14 11:31, Rowan Collins wrote: I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! To reply with a broken record of my own: E_STRICT does not indicate code that will break in a future version. Hiding E_STRICT notices will have absolutely no detrimental effect on your code, now or in the future. It is up to you if you want to improve the code by following the hints, or ignore them because the code works fine. So, no this is not at all similar to the problem of E_STRICT, because that problem is not real. So everything that currently requires e_strict disabled to allow it to work will continue to work in PHP7? Including the parts that have now been marked for removal since being deprecated since PHP5.3? You confuse E_STRICT with E_DEPRECATED. Without raising E_DEPRECATED in an earlier minor PHP release, a feature/construct cannot be removed from PHP. No - There have been several threads on deprecating things that are currently 'hidden' by e_strict. The confusion is created by having two incompatible styles of coding, and unless one brings the 'non-e_strict' code in to line with current practices it creates problems when other actions change the goal posts yet again. In practice ... NO the code does not work fine UNLESS you ensure that all of the infrastructure is still using old versions of libraries. And even then we still get white screen responses with changes of PHP versions. My point is that on one hand people are COMPLAINING that code such as PHP 4 Constructors is not being updated and then ALSO claiming that we don't need to ... PLEASE can we have a level playing field to code to! I still don't get get what problem this RFC is actually going to solve? I don't see a problem. Yes, PHP4 constructors are are old and should no longer be used. But there is no problem still supporting them. Raise an E_DEPRECATED for those, and be done with it. It's following through on that with the rest of the infrastructure which is the important thing. Once something is deprecated again simply hiding the error is not going to get legacy code up to date so it then fails when the target is actually removed. Perhaps what I AM asking, is just that we need a clean roadmap for PHP7 on just what will be retained. Some of that may well need a PHP5.7 to deprecate it and I'm not against this particular tidy up, but it does need to be planned in the right way. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Lester Caine wrote on 21/11/2014 13:27: No - There have been several threads on deprecating things that are currently 'hidden' by e_strict. The confusion is created by having two incompatible styles of coding, and unless one brings the 'non-e_strict' code in to line with current practices it creates problems when other actions change the goal posts yet again. So, that would be moving from E_STRICT (safe to hide) to E_DEPRECATED (less safe to hide). At that point, you can deal with the E_DEPRECATED notices *and carry on ignoring E_STRICT*. Unless you can name an example of something which went from E_STRICT to fatal error? If so, that specific case was a violation of process, and should be highlighted. The confusion is created by having two incompatible styles of coding I asked this before, and you didn't answer: can you name something which, when you fix the E_STRICT notice, makes your code incompatible with something else? Or something which, if you *ignore* an E_STRICT notice, refuses to work? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 21/11/14 14:15, Rowan Collins wrote: Lester Caine wrote on 21/11/2014 13:27: No - There have been several threads on deprecating things that are currently 'hidden' by e_strict. The confusion is created by having two incompatible styles of coding, and unless one brings the 'non-e_strict' code in to line with current practices it creates problems when other actions change the goal posts yet again. So, that would be moving from E_STRICT (safe to hide) to E_DEPRECATED (less safe to hide). At that point, you can deal with the E_DEPRECATED notices *and carry on ignoring E_STRICT*. Unless you can name an example of something which went from E_STRICT to fatal error? If so, that specific case was a violation of process, and should be highlighted. IF one is working through code to fix the deprecated warnings why would one not fix the remaining e_strict. In may cases they are all in the same area of the code base? That is the whole point here ... we can't assume that the code will continue to work in the future. The confusion is created by having two incompatible styles of coding I asked this before, and you didn't answer: can you name something which, when you fix the E_STRICT notice, makes your code incompatible with something else? Or something which, if you *ignore* an E_STRICT notice, refuses to work? TODAY things are a little tidier, and problems that were created over many upgrades and a lot of the problems have been fixed but it's the agro caused when third party libraries re-enabling e_strict, hosting changing settings for other reasons and problems like that. All cause problems which will only be cleared when all of the legacy code is updated ... which means making them e_strict compliant ... which IS under-way, but slow going. I have had many situations where having upgraded one library so it's then e_strict clean it has problems when used with it switched off. In my book, code runs clean, if it creates warnings/errors then it needs fixing, and so simply hiding these is what is not acceptable. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi, On Fri, 2014-11-21 at 16:48 +0900, Yasuo Ohgaki wrote: How about use INI until PHP8? No. php.ini needs less settings not more. Especially not for language things. This makes a mess for creating portable code. ze1 compat mode was a fault as were other ini settings we had. Let's not go there, again. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@php.net wrote: Dear Internals, I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. Cheers, Levi Morrison I'm +1 on this RFC. I've lost count of the number of times I had to debug some completely impossible behavior I got while writing quick testing code (which is obviously not namespaced), because I accidentally created a class Test with a method test or similar. I'm also pretty confident that we can provide robust tooling for automatically porting code to new constructors - including updating parent:: call references if need be. Don't see how that would be a particular issue here. Nikita
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Johannes Schlüter wrote on 21/11/2014 16:13: Hi, On Fri, 2014-11-21 at 16:48 +0900, Yasuo Ohgaki wrote: How about use INI until PHP8? No. php.ini needs less settings not more. Especially not for language things. This makes a mess for creating portable code. ze1 compat mode was a fault as were other ini settings we had. Let's not go there, again. I agree; the runtime environment is not the right scope to set such options. I do wonder if it would be useful to make more use of declare() though, which is scoped to a single file, and could be used like Perl's Pragmas. Annoyingly, unrecognised declare() options issue a warning, so you can't rely on older versions silently ignoring a new flag such as declare(compat_flags=php4_constructors); http://3v4l.org/cikUU Apparently, @ can't be used to suppress the warning, either, since the parser chokes (I guess because declare() isn't really a statement as such): http://3v4l.org/DFBfO I'm not sure it would actually make sense for this case, anyway, but some global behaviours would definitely benefit from being scoped this way e.g. suppress notices in deprecated / 3rd-party code, but show them in your own new modules, or ensure strlen is not over-ridden by mbstring in a library which needs to count bytes. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Nikita Popov wrote on 21/11/2014 16:22: I'm also pretty confident that we can provide robust tooling for automatically porting code to new constructors - including updating parent:: call references if need be. Don't see how that would be a particular issue here. Given the contents of your github repo, I'm inclined to take your word for it on that! :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
BTW, old constructor has problem with traits (is this mentioned already?) http://3v4l.org/KZKXo I suppose nobody is using this side effect in production code, but there would be number of users who are confused by this behavior. If I remember the source code correctly, this should be considered a bug. I will definitely look into this, regardless of the outcome of this RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, 2014-11-19 at 14:33 +, Alain Williams wrote:
How many servers are stuck on PHP 4 ?
Of those 'stuck' servers, how many have applications still under active
development ?
The point is: how many people would get annoyed if PEAR stopped supporting
PHP 4 ?
The point about breaking this is *not* PHP 4 compatibility but
compatibility between PECL packages. The name of the constructor method
is part of the API.
Think about code like this in module A:
class A_class {
function A_class() { }
}
and then module B extending this:
class B_class extends A_class {
function B_class() {
A_class();
}
}
I also wonder how Andrea's tool handles more indirect cases (C_class
extends B_class, while B_class has no ctor so C_class calls directly
A_class's ctor)
So I'm -1 on this.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Thu, Nov 20, 2014 at 5:43 PM, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2014-11-19 at 14:33 +, Alain Williams wrote:
How many servers are stuck on PHP 4 ?
Of those 'stuck' servers, how many have applications still under active
development ?
The point is: how many people would get annoyed if PEAR stopped supporting
PHP 4 ?
The point about breaking this is *not* PHP 4 compatibility but
compatibility between PECL packages. The name of the constructor method
is part of the API.
Think about code like this in module A:
class A_class {
function A_class() { }
}
and then module B extending this:
class B_class extends A_class {
function B_class() {
A_class();
}
}
I also wonder how Andrea's tool handles more indirect cases (C_class
extends B_class, while B_class has no ctor so C_class calls directly
A_class's ctor)
So I'm -1 on this.
I am with you here.
leave it there doesn't hurt anybody. but remove it will. why we need to ?
thanks
johannes
--
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] [RFC] Remove PHP 4 Constructors
Hi, On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui larue...@php.net wrote: leave it there doesn't hurt anybody. but remove it will. why we need to ? Leaving it does hurt. Most developers with no PHP4 experience don't know that such a feature exists and spend hours trying to figure out why a parent class' constructor isn't getting called when it's not overriden by self::__construct(). PHP can't support everything forever, old and nowadays rarely used syntax like this one must go away. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Thu, Nov 20, 2014 at 10:32 PM, Andrey Andreev n...@devilix.net wrote: Hi, On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui larue...@php.net wrote: leave it there doesn't hurt anybody. but remove it will. why we need to ? Leaving it does hurt. Most developers with no PHP4 experience don't know that such a feature exists and spend hours trying to figure out why a parent class' constructor isn't getting called when it's not overriden by self::__construct(). I really doubt most here. developers with c++ experience must feel it's very friendly. thanks PHP can't support everything forever, old and nowadays rarely used syntax like this one must go away. Cheers, Andrey. -- 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] [RFC] Remove PHP 4 Constructors
On Thu, Nov 20, 2014 at 2:43 AM, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2014-11-19 at 14:33 +, Alain Williams wrote:
How many servers are stuck on PHP 4 ?
Of those 'stuck' servers, how many have applications still under active
development ?
The point is: how many people would get annoyed if PEAR stopped supporting
PHP 4 ?
The point about breaking this is *not* PHP 4 compatibility but
compatibility between PECL packages. The name of the constructor method
is part of the API.
Think about code like this in module A:
class A_class {
function A_class() { }
}
and then module B extending this:
class B_class extends A_class {
function B_class() {
A_class();
}
}
I also wonder how Andrea's tool handles more indirect cases (C_class
extends B_class, while B_class has no ctor so C_class calls directly
A_class's ctor)
So I'm -1 on this.
I just want to make sure I understand you correctly: you are saying
you are voting no on this RFC because a tool, which is not part of
this RFC but we kindly provide, doesn't detect when a certain thing is
called?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Thu, 2014-11-20 at 09:11 -0700, Levi Morrison wrote: So I'm -1 on this. I just want to make sure I understand you correctly: you are saying you are voting no on this RFC because a tool, which is not part of this RFC but we kindly provide, doesn't detect when a certain thing is called? It is a non-trivial change. Fixing this is not always as some people might suggest. If we like it or not there is tons of code out there depending on this feature. Breaking code, which worked for 15 years, where we even distribute such code in our main distribution (pear.phar is full of it) is not an option. And it is not only PHP - just looked at wordpress and there are quite a few classes in there where PHP 4 style ctors are used.and which aren't marked final/public and as such are part of the API, meaning that WP modules might depend on that. Consequence there is that once the feature is removed WP users need a new major WP version and new versions of modules before they can upgrade. This will lead to very slow adoption of a new PHP version. We can deprecate it in 7 (and fix code in our distribution) and then take a next step in a later version, though. This gives folks like WP time to update their codebase and be ready when our larer version comes out. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Johannes Schlüter wrote on 20/11/2014 17:00: We can deprecate it in 7 (and fix code in our distribution) and then take a next step in a later version, though. This gives folks like WP time to update their codebase and be ready when our larer version comes out. +1 for officially deprecating this for a while before removing; currently, there's not even an E_STRICT when defining or using old-style constructors. The manual isn't particular clear either: For backwards compatibility, if PHP 5 cannot find a __construct() http://php.net/manual/en/language.oop5.decon.php#object.construct function for a given class, and the class did not inherit one from a parent class, it will search for the old-style constructor function, by the name of the class. I notice the RFC does propose deprecation, but in 5.7; that's predicated on a 5.7 being released, which I know some people are not in favour of. Has there been a formal vote on whether 5.7 should exist as a lightweight last 5.x shortly before 7.x? Even with that, there is the question of whether 5.7 would give users long enough to make sure everything was compatible with this change. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
I just want to make sure I understand you correctly: you are saying you are voting no on this RFC because a tool, which is not part of this RFC but we kindly provide, doesn't detect when a certain thing is called? It is a non-trivial change. Fixing this is not always as some people might suggest. 1) Identify PHP 4 constructors using one of several tools (including upgrading to PHP 5.7 and getting E_DEPRECATEDs). 2) Use one of the several tools that support method rename refactoring (Netbeans, PhpStorm, and others) to rename the methods to __construct. You could probably automate it with a very high degree of success; I just don't want to automatically change code for liability reasons. I think you are exaggerating the required work given the tools we have at our disposal… …but that's okay. You can think and vote however you chose. We can deprecate it in 7 (and fix code in our distribution) and then take a next step in a later version, though. I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using multiple default statements in switches (which was accepted, by the way). Updating to PHP 5.7 first gives you more time to prepare for this and other BC breaks for PHP 7. There are already a few, and I suspect we'll have a few more before it's shipped. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On 20 November 2014 20:54:00 GMT, Levi Morrison le...@php.net wrote: I just want to make sure I understand you correctly: you are saying you are voting no on this RFC because a tool, which is not part of this RFC but we kindly provide, doesn't detect when a certain thing is called? It is a non-trivial change. Fixing this is not always as some people might suggest. 1) Identify PHP 4 constructors using one of several tools (including upgrading to PHP 5.7 and getting E_DEPRECATEDs). 2) Use one of the several tools that support method rename refactoring (Netbeans, PhpStorm, and others) to rename the methods to __construct. You could probably automate it with a very high degree of success; I just don't want to automatically change code for liability reasons. I think you are exaggerating the required work given the tools we have at our disposal… The problem is that the constructor is part of the public API (for inheritance purposes) so the required refactoring is not necessarily isolated to one project, or even doable by one developer. The maintainer of the library must first release a version with the new constructors in place, and the consumer of the library must then audit their code for anything relying on the old constructor. Supporting various combinations of PHP 5/7, old/new lib, and old/new consumer code is then messy at best. I agree that it's perfectly doable, but it's not as easy to migrate as, say, a syntax change. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Thu, 2014-11-20 at 13:54 -0700, Levi Morrison wrote: It is a non-trivial change. Fixing this is not always as some people might suggest. 1) Identify PHP 4 constructors using one of several tools (including upgrading to PHP 5.7 and getting E_DEPRECATEDs). 2) Use one of the several tools that support method rename refactoring (Netbeans, PhpStorm, and others) to rename the methods to __construct. You could probably automate it with a very high degree of success; I just don't want to automatically change code for liability reasons. I think you are exaggerating the required work given the tools we have at our disposal… No you can't. (ok *you* can but not 90% of our users, those depend on external libraries/tools and those can't simply change their API without hurting their adoption rate, which in turn hurts our adoption rate) I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using multiple default statements in switches (which was accepted, by the way). Updating to PHP 5.7 first gives you more time to prepare for this and other BC breaks for PHP 7. There are already a few, and I suspect we'll have a few more before it's shipped. Yay! Instead of helping users to keep up to date and respecting their needs we give them reasons to stay on old versions for making things cleaner. How wonderful. All things said for this thread. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi all, On Fri, Nov 21, 2014 at 6:39 AM, Johannes Schlüter johan...@schlueters.de wrote: I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using multiple default statements in switches (which was accepted, by the way). Updating to PHP 5.7 first gives you more time to prepare for this and other BC breaks for PHP 7. There are already a few, and I suspect we'll have a few more before it's shipped. Yay! Instead of helping users to keep up to date and respecting their needs we give them reasons to stay on old versions for making things cleaner. How wonderful. All things said for this thread. How about use INI until PHP8? BTW, old constructor has problem with traits (is this mentioned already?) http://3v4l.org/KZKXo I suppose nobody is using this side effect in production code, but there would be number of users who are confused by this behavior. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison le...@php.net wrote: I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. No reason to keep old constructor for PHP7. IMHO. +1 for removing it PHP7, announce depreciation now. This is obviously a +1. Julien.Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Le Wed Nov 19 2014 at 9:31:50 AM, Julien Pauli jpa...@php.net a écrit : On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison le...@php.net wrote: I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. No reason to keep old constructor for PHP7. IMHO. +1 for removing it PHP7, announce depreciation now. This is obviously a +1. Julien.Pauli +1
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@php.net wrote: Dear Internals, I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If accepted, methods with the same name as their defining class will no longer be recognized as constructors. As noted in the RFC, there are already many situations where we do not recognize these methods as constructors, such as in namespaces and traits and when `function __construct` is also present. Andrea Faulds has kindly written a utility that identifies when a PHP 4 constructor is defined[2]. It does not automatically change the code for liability reasons. The utility PHPMD[3] can also detect this but has a false positive when `__construct` is also defined. Cheers, Levi Morrison [1]: https://wiki.php.net/rfc/remove_php4_constructors [2]: https://github.com/TazeTSchnitzel/PHP4_Constructor_Finder [3]: http://phpmd.org/rules/naming.html#constructorwithnameasenclosingclass -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 from me. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/11/2014 00:11, Levi Morrison a écrit : [1]: https://wiki.php.net/rfc/remove_php4_constructors This will just kill PEAR and most of available libraries on PEAR forge. Yes they are still some use of them Yes keeping PHP 4 for PEAR is a bad idea Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRsniIACgkQYUppBSnxahilDwCgtcsNH9UtJFtkVkY0KwqxRiZn oZgAoLzKJ4zbO6mBerkivLziwFahOAF/ =pQ60 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
On Wed, Nov 19, 2014 at 02:41:54PM +0100, Remi Collet wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/11/2014 00:11, Levi Morrison a écrit : [1]: https://wiki.php.net/rfc/remove_php4_constructors This will just kill PEAR and most of available libraries on PEAR forge. Yes they are still some use of them Yes keeping PHP 4 for PEAR is a bad idea Maybe this would spur PEAR to moving to a modern PHP, they could always maintain a separate PEAR legacy. PHP 4 support ended some 6 years ago. -- 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
