# [RFC Proposal] var keyword deprecation/removal - Thread: https://externals.io/message/91430 - Original archive: https://news-web.php.net/php.internals/91430 - Started by Tony Marston on 2016-02-26T09:46:52+00:00 - Messages: 77 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/91430.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #91430 — Tony Marston — 2016-02-26T09:46:52+00:00 URL: https://externals.io/message/91430#91430 Sent: Thursday, February 25, 2016 12:58 PM >To: Tony Marston >Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal >Hi Tony, > >Thank you so much for your feedback. You make some really good, valid >points. If I may provide some responses to some of them: > > > […] > >I downloaded and scanned the top 10,000 projects on Packagist (including >their dependencies). So you examined a bunch of source files in one location? What about those projects that aren't maintained on Packagist? Mine certainly isn't. >Only 4% use "var". I looked closer into that 4% and found almost 2/3rds >were due to a handful of prominent packages being required as dependencies. >Adjusting these packages would drastically lower overall usage across the >ecosystem. And because "var" is simply an alias for "public", making that >change would only require a bump in the patch version. > >I'm not 100% happy with my methodology because the dependencies are counted >multiple times. When I have some time I'll revise my approach to get >more-accurate figures. The only way to obtain what could be called "accurate" figures would be to examine every PHP script ever written. What you have is nothing more than a small sample. > > […] > > >Here's a simple PHP script which does this automatically: >https://gist.github.com/colinodell/5fb5e5d474674f294a38 Because "public" >is supported in 5.x and 7.x, programmers could run this script at any time >before the 8.0 release (assuming this proposed RFC passes and the >programmer wants their code to run on 8.0). > > > […] > > >I will happily make that change myself. > > > > […] > > >I'm hoping that the automated upgrade script and advance warning would help >mitigate that impact. I, and others, will object to having to run any sort of conversion scripts just because you personally don't like the "var" keyword. It does no harm, so there is no benefit to be had by taking it out. -- Tony Marston --- ## #91447 — kelerest123@gmail.com — 2016-02-28T06:18:34+00:00 URL: https://externals.io/message/91430#91447 · In reply to: #91430 Good morning Internals! I am strongly AGAINST the removal of the `var` keyword from PHP syntax. Though in general it's an alias of `public` (or it simply ‘acts’ as the `public` modifier), I see a difference in its _semantics_. While the `public` modifier states anyone can change the property, `var` is useful for marking internal properties which must be public, but should not be manipulated by simply anybody e.g. in the case of dependency injection: fooService thanks to DI container } } ?> This idea comes to me from using the Nette Framework, which handles DI automatically and this way -- using `var` -- one can semantically mark, which are the internally @inject'ed properties and differ them from the `public` ones. > Sent: Thursday, February 25, 2016 12:58 PM > > […] > > > So you examined a bunch of source files in one location? What about those > projects that aren't maintained on Packagist? Mine certainly isn't. > > > […] > > > The only way to obtain what could be called "accurate" figures would be to > examine every PHP script ever written. What you have is nothing more than a > small sample. > > > […] > > > I, and others, will object to having to run any sort of conversion scripts > just because you personally don't like the "var" keyword. It does no harm, > so there is no benefit to be had by taking it out. > > > -- > Tony Marston > > > -- > > > Thanks! -- Cheers, Kubis --- ## #91450 — James Titcumb — 2016-02-28T09:49:59+00:00 URL: https://externals.io/message/91430#91450 · In reply to: #91447 > > I see a difference in its > _semantics_. While the `public` modifier states anyone can change the > property, `var` is useful for marking internal properties which must > be public, but should not be manipulated by simply anybody If it's public, it will be modified by someone. This isn't an intended semantic meaning of `var`, and simply saying "don't modify this please" is never going to be enough. Make them private, protected or public and make your intent clear, because for anyone unfamiliar with this design will simply translate `var` to mean `public`, and use it as such. --- ## #91457 — Tony Marston — 2016-02-29T09:55:18+00:00 URL: https://externals.io/message/91430#91457 · In reply to: #91450 "James Titcumb" wrote in message news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com... > > > > […] > >If it's public, it will be modified by someone. Incorrect. It *may* be modified, but surely any invalid modifications will be detected in the testing phase? > This isn't an intended >semantic meaning of `var`, and simply saying "don't modify this please" is >never going to be enough. Make them private, protected or public and make >your intent clear, because for anyone unfamiliar with this design will >simply translate `var` to mean `public`, and use it as such. If "var" is automatically translated into "public", and has been since PHP 5 emerged, and has been documented to behave in this way, then what does it cost to leave it that way? Answer: NOTHING! -- Tony Marston --- ## #91458 — Rowan Collins — 2016-02-29T11:34:43+00:00 URL: https://externals.io/message/91430#91458 · In reply to: #91457 Tony Marston wrote on 29/02/2016 09:55: > "James Titcumb" wrote in message > news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com... > > > […] > > Incorrect. It *may* be modified, but surely any invalid modifications > will be detected in the testing phase? Detected by whom? Using what tool? I'm not aware of any generic way of logging all access to particular properties, nor quite what "invalid modifications" mean in this labelling scheme. Maybe it would be detected during *review*? Apologies if that's what you meant and the distinction sounds pedantic. A better way to mark this kind of distinction is using PHPDoc annotations, which can be made readable by both humans and tools. For instance, PHPStorm will cross through any uses of a property marked "@internal"; I wouldn't be surprised if other IDEs and tools can pick this up as well. In this case, you could just use the fact that the property is labelled "@inject" to mark the distinction, and you'd be no worse off in terms of tooling support than you are now (i.e. IDEs will not come with this interpretation of "var" baked in anyway). Regards, -- Rowan Collins [IMSoP] --- ## #91464 — Tony Marston — 2016-03-01T09:32:55+00:00 URL: https://externals.io/message/91430#91464 · In reply to: #91458 "Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com... > >Tony Marston wrote on 29/02/2016 09:55: > > […] > >Detected by whom? Using what tool? If changing a variable directly instead of using a setter does not produce an error that can be detected in your testing, whether that testing is automated or manual, then is there actually an error? If doing something does not cause a problem there there is no problem that needs fixing. Preventing something from happening which does not cause an error even if it did happen seems like wasted effort to me. -- Tony Marston --- ## #91465 — kelerest123@gmail.com — 2016-03-01T09:52:04+00:00 URL: https://externals.io/message/91430#91465 · In reply to: #91457 > If "var" is automatically translated into "public", and has been since PHP 5 > emerged, and has been documented to behave in this way, then what does it > cost to leave it that way? Answer: NOTHING! Yeah. This is actually very true. -- Cheers, Kubis --- ## #91466 — Rowan Collins — 2016-03-01T11:33:08+00:00 URL: https://externals.io/message/91430#91466 · In reply to: #91464 Tony Marston wrote on 01/03/2016 09:32: > "Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com... > > […] > > If changing a variable directly instead of using a setter does not > produce an error that can be detected in your testing, whether that > testing is automated or manual, then is there actually an error? If > doing something does not cause a problem there there is no problem > that needs fixing. Preventing something from happening which does not > cause an error even if it did happen seems like wasted effort to me. > Firstly, no test suite can ever truly cover 100% of scenarios that the live application will encounter, so the idea that a bug doesn't exist until it causes an error is asking for trouble. You want to catch mistakes as early as possible, and that is exactly what member visibility is there for in the first place - to stop you in your tracks if you try to access something that was supposed to be internal. Secondly, violating visibility may have repercussions outside actual errors. Consider something relying on accessing an "internal" property and writing dozens of lines of code assuming it is of a particular type. Then consider that the maintainer of the module which declared it refactors and removes, renames, or changes the type of that property, confident that they are safe to do so because it was for internal use only. The result is much more wasted effort than keeping an eye out that you're not violating visibility in the first place. Regards, -- Rowan Collins [IMSoP] --- ## #91470 — Rowan Collins — 2016-03-01T17:34:37+00:00 URL: https://externals.io/message/91430#91470 · In reply to: #91466 Rowan Collins wrote on 01/03/2016 11:33: > > Secondly, violating visibility may have repercussions outside actual > errors. Incidentally, PHP itself encountered this a few years ago, where a release of libxml2 changed internal behaviour that was being relied on for a hack. The result was that entities like > started silently disappearing from everyone's parsed XML if they compiled PHP against the new library. See https://bugs.php.net/bug.php?id=45996 and http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 Regards, -- Rowan Collins [IMSoP] --- ## #91471 — Fleshgrinder — 2016-03-01T18:21:26+00:00 URL: https://externals.io/message/91430#91471 · In reply to: #91470 > Rowan Collins wrote on 01/03/2016 11:33: > > […] > > > Incidentally, PHP itself encountered this a few years ago, where a > release of libxml2 changed internal behaviour that was being relied on > for a hack. The result was that entities like > started silently > disappearing from everyone's parsed XML if they compiled PHP against the > new library. See https://bugs.php.net/bug.php?id=45996 and > http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 > > Regards, The misuse of "var" as it was explained is reason alone to take action. -- Richard "Fleshgrinder" Fussenegger --- ## #91473 — Tony Marston — 2016-03-02T09:53:59+00:00 URL: https://externals.io/message/91430#91473 · In reply to: #91471 wrote in message news:56D5DDA6.4080607@fleshgrinder.com... > > > > […] > >The misuse of "var" as it was explained is reason alone to take action. Just because one developer out of millions made a mistake is no reason to punish those millions. If "var" can be abused then "public" can be abused in the same way, so surely the only way to avoid the possibility of ANY abuse whatsoever would be to remove "public" as well as "var". -- Tony Marston --- ## #91474 — Rowan Collins — 2016-03-02T10:09:20+00:00 URL: https://externals.io/message/91430#91474 · In reply to: #91473 Tony Marston wrote on 02/03/2016 09:53: > wrote in message news:56D5DDA6.4080607@fleshgrinder.com... > > […] > > Just because one developer out of millions made a mistake is no reason > to punish those millions. > > If "var" can be abused then "public" can be abused in the same way, so > surely the only way to avoid the possibility of ANY abuse whatsoever > would be to remove "public" as well as "var". > I think the point was that *the difference between* "var" and "public" was being abused, which wouldn't be possible if there were only one keyword. However, I agree that it's a very weak argument for removal (just as "I [ab]use 'var' to mean something different from 'public'" is a weak argument against removal). Regards, -- Rowan Collins [IMSoP] --- ## #91476 — Fleshgrinder — 2016-03-02T18:40:06+00:00 URL: https://externals.io/message/91430#91476 · In reply to: #91474 > I think the point was that *the difference between* "var" and "public" > was being abused, which wouldn't be possible if there were only one > keyword. > > However, I agree that it's a very weak argument for removal (just as "I > [ab]use 'var' to mean something different from 'public'" is a weak > argument against removal). > > Regards, It showcases what the studies about UI/UX found out about duplicated behavior (or call it aliasing, multiple choices for the same thing, ...). People are confused and we can and should avoid that. The "var" keyword once emitted an `E_STRICT` but I guess it was turned off again because too many people were complaining as they are now. -- Richard "Fleshgrinder" Fussenegger --- ## #91477 — Tony Marston — 2016-03-03T09:34:20+00:00 URL: https://externals.io/message/91430#91477 · In reply to: #91476 wrote in message news:56D73386.3000903@fleshgrinder.com... > > > > […] > >It showcases what the studies about UI/UX found out about duplicated >behavior (or call it aliasing, multiple choices for the same thing, ...). > >People are confused and we can and should avoid that. Only some people are confused. But that confusion goes away once they RTFM (Read The Friendly Manual). If you want to avoid such confusion over alias names then surely that would be an argument against introducing aliases in the first place. In this case the short array syntax would never have been introduced as the (only slightly longer) long array syntax had already existed since day #1. >The "var" keyword once emitted an `E_STRICT` but I guess it was turned off >again because too many people were complaining as they are now. > So if people are still using it then surely that is an argument AGAINST its removal. -- Tony Marston --- ## #91478 — Lester Caine — 2016-03-03T10:04:35+00:00 URL: https://externals.io/message/91430#91478 · In reply to: #91477 > > […] > > So if people are still using it then surely that is an argument AGAINST > its removal. The underlying problem here IS things like `E_STRICT` and E_DEPRECATED. On one hand YES you can get legacy code working by hiding the warnings, but that only makes the problem worse when someone actually completes the cycle and removes the keyword. Getting code through the PHP5.2/3/4 cycles did require leaving all messages visible and handling each as required. The problem with 'var' is that while one should probably replace them all with public, there is a lot of simple legacy code still in active use that could take years to 'tidy' and for no gain what so ever? A quick scan of my current code base shows several thousand hits on 'var ' in both third party libraries, stock code and private stuff. Only a small percentage are 'actually' replaceable by public but the time to go through and manually check each one ... is it THAT much of a problem? -- 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 --- ## #91479 — Colin O'Dell — 2016-03-03T12:47:46+00:00 URL: https://externals.io/message/91430#91479 · In reply to: #91478 Lester, > The problem with 'var' is that while one should probably > replace them all with public, there is a lot of simple legacy code still > in active use that could take years to 'tidy' 'var' would not be removed until 8.x, so you'd have several years before needing to make code changes. Additionally, the RFC will include this script which automatically upgrades legacy code in mere seconds: https://gist.github.com/colinodell/5fb5e5d474674f294a38 If you're staying on PHP 5.x or 7.0, no changes would be needed. If you're upgrading to 7.1+, you would need to either hide deprecation notices or take 30 seconds to run that script. > Only a small percentage are 'actually' replaceable by public My understanding is that 'var' is simply an alias for 'public' so they should behave identically. Could you please provide an example where 'var' is not replaceable by 'public'? Thanks for your feedback! Colin O'Dell --- ## #91480 — Rowan Collins — 2016-03-03T13:04:56+00:00 URL: https://externals.io/message/91430#91480 · In reply to: #91479 Colin O'Dell wrote on 03/03/2016 12:47: > If you're staying on PHP 5.x or 7.0, no changes would be needed. If you're > upgrading to 7.1+, you would need to either hide deprecation notices or > take 30 seconds to run that script. This isn't quite true. At the moment, PHP has no mechanism for hiding notices within particular libraries, so if you're using a third-party library, you have to either persuade the maintainer to put out a new release, or maintain a fork, either of which may require significant effort. > My understanding is that 'var' is simply an alias for 'public' so they > should behave identically. Could you please provide an example where 'var' > is not replaceable by 'public'? I'm not sure what Lester had in mind, but in many cases legacy code which used "var" should actually be updated to mark properties as "protected" or "private" instead. Such properties are public only because PHP4 had no other visibility, and explicitly marking them all as "public" simply masks the real job, which is assessing which visibility each property should have. It occurs to me that if I saw "var", I would not think "that should be public", but "that needs assessing for visibility". I do the same with legacy code where methods are written as "function foo()" rather than "public function foo()" - I check whether it should actually be public, and also in that case whether it should be static. Regards, -- Rowan Collins [IMSoP] --- ## #91481 — Lester Caine — 2016-03-03T13:18:49+00:00 URL: https://externals.io/message/91430#91481 · In reply to: #91480 > Colin O'Dell wrote on 03/03/2016 12:47: > > […] > > This isn't quite true. At the moment, PHP has no mechanism for hiding > notices within particular libraries, so if you're using a third-party > library, you have to either persuade the maintainer to put out a new > release, or maintain a fork, either of which may require significant > effort. Additionally we ARE still having to maintain older versions of these same libraries ... > > […] > > I'm not sure what Lester had in mind, but in many cases legacy code > which used "var" should actually be updated to mark properties as > "protected" or "private" instead. Such properties are public only > because PHP4 had no other visibility, and explicitly marking them all as > "public" simply masks the real job, which is assessing which visibility > each property should have. > > It occurs to me that if I saw "var", I would not think "that should be > public", but "that needs assessing for visibility". I do the same with > legacy code where methods are written as "function foo()" rather than > "public function foo()" - I check whether it should actually be public, > and also in that case whether it should be static. Actually my problem is even more simple than that - although it may be possible to further filter the lookup for 'var ' ( note the space ) many of the results are simply not text that needs changing. Many previous changes have been possible simply with a global replaceand pick up the odd mistake. var is simply not a candidate for that so while many results can simply be skipped, each has to be reviewed and at that point one may want to use something other than just public. -- 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 --- ## #91482 — Rowan Collins — 2016-03-03T13:24:10+00:00 URL: https://externals.io/message/91430#91482 · In reply to: #91481 Lester Caine wrote on 03/03/2016 13:18: > Actually my problem is even more simple than that - although it may be > possible to further filter the lookup for 'var ' ( note the space ) many > of the results are simply not text that needs changing. The script that Colin linked (https://gist.github.com/colinodell/5fb5e5d474674f294a38) uses an in-language tokenizer, not just text find-and-replace, so this is a solved problem. If this turns out to not be smart enough, one built on top of Nikita's PHP-Parser project would be pretty easy as well: https://github.com/nikic/PHP-Parser/ Regards, -- Rowan Collins [IMSoP] --- ## #91483 — johannes@schlueters.de — 2016-03-03T14:08:30+00:00 URL: https://externals.io/message/91430#91483 · In reply to: #91476 > It showcases what the studies about UI/UX found out about duplicated > behavior (or call it aliasing, multiple choices for the same thing, ...). > > People are confused and we can and should avoid that. Yes, duplication isn't good and we should avoid adding new duplication without a good reason. However breaking compatibility isn't good either. Adding breaks not only invalidates code but also tutorials, books, etc. which might confuse readers more (while I admit, that a book teaching "var" might be questionable in other ways, too) Quick Googling brings this tutorial, which first teaches "var" to get started and then changes to public/private/protected in a later step: http://www.killerphp.com/tutorials/php-objects-page-3/ > The "var" keyword once emitted an `E_STRICT` but I guess it was turned off > again because too many people were complaining as they are now. One could argue those were other times - I doubt anybody maintains a single code base for both PHP 4 and PHP 7. While in early PHP 5 times it had been common that people tried to produce code working on PHP 4 and PHP 5 without notices. johannes --- ## #91487 — Fleshgrinder — 2016-03-03T16:53:20+00:00 URL: https://externals.io/message/91430#91487 · In reply to: #91477 > If you want to avoid such confusion over alias names then surely that > would be an argument against introducing aliases in the first place. In > this case the short array syntax would never have been introduced as the > (only slightly longer) long array syntax had already existed since day #1. No, that is not what one should conclude from it. Short array syntax was added by popular demand and hence for a very good reason. The fact that there are no plans regarding the old syntax and thus keeping the duplication indefinitely is the actual problem. Change for the sake of change is bad, no argument there. Change for the sake of progress is not and totally normal. > I'm not sure what Lester had in mind, but in many cases legacy code > which used "var" should actually be updated to mark properties as > "protected" or "private" instead. Such properties are public only > because PHP4 had no other visibility, and explicitly marking them all > "public" simply masks the real job, which is assessing which > visibility each property should have. > > It occurs to me that if I saw "var", I would not think "that should be > public", but "that needs assessing for visibility". I do the same with > legacy code where methods are written as "function foo()" rather than > "public function foo()" - I check whether it should actually be > public, and also in that case whether it should be static. It seems as if this is not the issue for the people who are against removing the "var" keyword from PHP 8. They simply do not want to change their scripts at all. The described procedure is truly time consuming since it involves to check all usages everywhere as well. Simply changing from "var" or "public" to any other visibility is a brutal change. -- Richard "Fleshgrinder" Fussenegger --- ## #91488 — Rowan Collins — 2016-03-03T17:14:36+00:00 URL: https://externals.io/message/91430#91488 · In reply to: #91487 Fleshgrinder wrote on 03/03/2016 16:53: > The fact that > there are no plans regarding the old syntax and thus keeping the > duplication indefinitely is the actual problem. Having no plans to use something doesn't make it a problem. There still needs to be some actual problem you are solving by removing it. > > […] > It seems as if this is not the issue for the people who are against > removing the "var" keyword from PHP 8. They simply do not want to change > their scripts at all. The described procedure is truly time consuming > since it involves to check all usages everywhere as well. Simply > changing from "var" or "public" to any other visibility is a brutal change. Let's not make generalisations about people's motives here. I am expressing *my* reasoning for being against removal; others may have other reasons, and you can discuss those with them. My point was that bulk changing "var" to "public" is a counter-productive change. It removes the information "this property's visibility has not been reviewed", without actually adding any value. This leaves us with a small gain (clearer to new users that the correct keyword is "public"), and two small costs (the need to run a script over all existing code to change "var" to "public", and the loss of opportunity to manually review all instances of "var"); I'm not willing to quantify those, but the balance doesn't feel in favour of change to me. If there were some way of preventing users writing var in *new* code, I would be all for it - there is no advantage to doing so, and it adds no value to have two ways of writing "public". But there is no way for the engine to distinguish new code from "legacy" code which already contains the keyword. If someone can come up with a clean mechanism for doing that (and in particular, for new code to say "I'm including this legacy library which I will replace with modern code shortly, don't bother telling me how many deprecated features it uses"), then I would be very interested. Regards, -- Rowan Collins [IMSoP] --- ## #91489 — Fleshgrinder — 2016-03-03T17:32:26+00:00 URL: https://externals.io/message/91430#91489 · In reply to: #91488 > Having no plans to use something doesn't make it a problem. There still > needs to be some actual problem you are solving by removing it. I think in general that it would be helpful to have clear guidelines regarding such topics. They would make deprecation discussions in general simpler. > Let's not make generalisations about people's motives here. I am > expressing *my* reasoning for being against removal; others may have > other reasons, and you can discuss those with them. :) > My point was that bulk changing "var" to "public" is a > counter-productive change. It removes the information "this property's > visibility has not been reviewed", without actually adding any value. I understood your motivation and it is a very valid as well as honorable one. > This leaves us with a small gain (clearer to new users that the correct > keyword is "public"), and two small costs (the need to run a script over > all existing code to change "var" to "public", and the loss of > opportunity to manually review all instances of "var"); I'm not willing > to quantify those, but the balance doesn't feel in favour of change to me. > > If there were some way of preventing users writing var in *new* code, I > would be all for it - there is no advantage to doing so, and it adds no > value to have two ways of writing "public". But there is no way for the > engine to distinguish new code from "legacy" code which already contains > the keyword. If someone can come up with a clean mechanism for doing > that (and in particular, for new code to say "I'm including this legacy > library which I will replace with modern code shortly, don't bother > telling me how many deprecated features it uses"), then I would be very > interested. I always thought that `E_STRICT` is exactly that. I mean, an upgrade path like ... # do nothing in PHP 5 (as is), # emit `E_STRICT` in PHP 7, # emit `E_DEPRECATED` in PHP 8, # remove in PHP 9 ... would be fine with me too and go back to what I said initially: a clear policy. Note that it would add several more years to the upgrade path (6 years?). Of course it is bad that people simply suppress those errors but that is something that is completely out of control for us. People could easily log them into a separate log as well during development and disable them in production ... Such a practice could also be easily applied to the RFC that proposes to clean up many old inconsistent functions ... # do nothing in PHP 7, # emit `E_STRICT` in PHP 8, # emit `E_DEPRECATED` in PHP 9, # remove in PHP 10. That results in around 9 years of time to adopt. https://wiki.php.net/rfc/consistent_function_names The biggest problem is when languages change to fast and for no real benefit as we have seen it with many other languages and it almost happened with PHP 6 (although the intention was good there). -- Richard "Fleshgrinder" Fussenegger --- ## #91490 — Rowan Collins — 2016-03-03T17:48:25+00:00 URL: https://externals.io/message/91430#91490 · In reply to: #91489 Fleshgrinder wrote on 03/03/2016 17:32: > > […] > I always thought that `E_STRICT` is exactly that. I mean, an upgrade path > like ... There's a subtle distinction which I may not have explained very well. What I want is the ability to *selectively* ignore these warnings. For instance, if I write: namespace \Foo\Bar\Baz; class AwesomenessFactory implements ArrayAccess { var $something; } ... then I would be happy to see a notice that I'd used the wrong keyword. But if I write: # TODO Replace dependency with modern equivalent include 'Ancient/PEAR/Library.php'; ... then I don't want to see 500 notices that the library I'm about to replace has old-fashioned code in it. The same is true if I am actually maintaining the included library, and have a rewrite in the works which I am confident will supersede the current stable version long before the next major version of PHP. It's not about whether those notices are there for 6 years or 9 years, or which E_* constant they appear under, it's about granularity of which ones shout at me. Regards, -- Rowan Collins [IMSoP] --- ## #91491 — Fleshgrinder — 2016-03-03T18:55:14+00:00 URL: https://externals.io/message/91430#91491 · In reply to: #91490 > There's a subtle distinction which I may not have explained very well. > What I want is the ability to *selectively* ignore these warnings. For > instance, if I write: > > namespace \Foo\Bar\Baz; > class AwesomenessFactory implements ArrayAccess { > var $something; > } > > ... then I would be happy to see a notice that I'd used the wrong keyword. > > But if I write: > > # TODO Replace dependency with modern equivalent > include 'Ancient/PEAR/Library.php'; > > ... then I don't want to see 500 notices that the library I'm about to > replace has old-fashioned code in it. The same is true if I am actually > maintaining the included library, and have a rewrite in the works which > I am confident will supersede the current stable version long before the > next major version of PHP. > > It's not about whether those notices are there for 6 years or 9 years, > or which E_* constant they appear under, it's about granularity of which > ones shout at me. The closest we have to achieve this is ignore_repeated_errors plus ignore_repeated_source. However, you would still get one entry per request/process/... https://secure.php.net/errorfunc.configuration -- Richard "Fleshgrinder" Fussenegger --- Next page: https://externals.io/message/91430.md?page=2