Re: [PHP-DEV] [RFC] Reclassifying engine warnings
That's a good point, maybe a compromise is this: Matthew Brown hat am 28. August 2019 um 18:21 > geschrieben: > > > FWIW: all the runtime notices in our codebase come from internally-created > code. > > Requiring declare(strict_variables=1) to get this (better) behaviour punishes > future users of PHP for our past mistakes. > > On Aug 28, 2019, at 12:05 PM, Thomas Bley wrote: > > > > Normally every code base has old and new code, some is actively maintained, > > some is probably third-party maintained, some is unmaintained. Business > > normally not calculates costs for upgrading, securing, GDPRing old code, so > > bigger changes always leave some people behind. > > I would prefer to write new code with sth like declare(strict_variables=1); > > or declare(SomeNamespace\Foo:strict_variables=1); That way, people can > > write new code in a better way, include new libraries and upgrade old code > > piece by piece without any big pressure. > > > > Regards > > Thomas > > > Matthew Brown hat am 28. August 2019 um 17:32 > > > geschrieben: > > > > > > > > > It's essentially tech debt, and the language has allowed its users to > > > accrue a ton of it. > > > > > > The longer that's allowed (deprecations/warnings prolong the issue in my > > > opinion) the harder it will be to fix the issues. > > > > On Wed, 28 Aug 2019 at 10:56, Rowan Collins > > > > wrote: > > > > On 28 August 2019 15:22:22 BST, Matthew Brown > > > > wrote: > > > > > Looking at our notice logs, I estimate (fairly roughly) that it would > > > > > require about a week's worth of my time to fix these issues > > > > I honestly thought you were posting that as an argument against. A week > > > > of > > > > resource (plus the accompanying QA impact etc) is a significant > > > > investment > > > > for many organisations. That's why it has the potential to delay > > > > adoption > > > > of a new version, and why a long lead-in via deprecation or opt-in is > > > > necessary. > > > > Regards, > > > > -- > > > > Rowan Collins > > > > [IMSoP] > > > > -- > > > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
On Sat, 31 Aug 2019 at 02:31, Larry Garfield wrote: > [..] > Whether editions is the "right" way to balance "don't break 1 million lines > of 15 year old code" with "this behavior is bad and we all know it" and with > "this behavior leads to sloppy code that is prone to bugs", I don't know. > I'm not sure what my stance is on these questions yet. To me the main challenges seem to be to find a syntax that feels natural, and then the technical feasibility of actually implementing and maintaining this in the engine. It probably does feel awkward to have declarations on top of every file. And it would mean you need to make a conscious choice for every new file and every new library. Not just a "yes or now", but to pick a specific version or edition number. You would periodically modify your code to increase this number. So doing this on "package level", whatever this means, would have clear advantages. To some extent this awkwardness could be seen as the price for having a language that historically started somewhere very different from where we would like to see it in the future. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
Some clarifications before I get crucified: > "editions" (the way I imagine) I don't want to misrepresent Nikita. His idea of editions might be completely different. > If "editions" (the way I imagine) had been introduced prior to PHP 7, we > might now have a PHP 7 engine that would still support code written for PHP > 5.x. Of course in general, most of the code "written for PHP 5.x" already works in PHP 7. Except when it doesn't. But the argument goes further. If "editions" had been around earlier, perhaps the opt-in flavor of PHP 7.n would already be more strict than it the non-opt-in flavor of PHP 7.n is now. Having the possibility to let files opt-in can allow for bolder and faster innovation, with less holding back. On Sat, 31 Aug 2019 at 03:52, Andreas Hennings wrote: > > On Sat, 31 Aug 2019 at 03:40, Reindl Harald wrote: > > > > > > > > Am 30.08.19 um 20:56 schrieb Andreas Hennings: > > > In one of -these modules I initially used the ?? null coalesce operator. > > > Then I had to replace all of the instances of ?? with the more verbose > > > old-school code, to make it compatible with older PHP, because there > > > are still enough Drupal 7 installations out there which have not > > > upgraded to PHP 7 yet. > > > I also had issues with old 3rd party libraries, which stood in the way > > > of PHP version upgrade. > > > > > > In a world with "editions" per file or per package, such projects > > > could more easily use the newest PHP version, while the old libraries > > > would continue working. > > > > no, it could not, when these days installations aren't running PHP7 at > > all you won#t have support for new features > > If "editions" (the way I imagine) had been introduced prior to PHP 7, > we might now have a PHP 7 engine that would still support code written > for PHP 5.x. > > There is a limit in how far this makes sense. In a lot of cases, what > "breaks" in PHP7 was already broken to begin with. > So in a way the BC breaks can be a good thing, they force people to > fix the mistakes from the past. > > > > > you can declare what you want on top of the file - when the server is > > sloppy mainatined and running stone old software you simply can't use a > > recent feature > > > > just stop supporting such unmaintained setups and they will disappear, > > break them as hard as you can! > > > you need to distinguish two different things here: > - server infrastructure / php version. > - the actual PHP code in the project, which might be a collection of > custom code and various 3rd party packages with different age. > > upgrading the server infrastructure and php version is easy, compared > to upgrading or fixing the PHP code itself. > The only reason why people might stick with an old infrastructure and > php version is because the new version might break their legacy PHP > code. > > As said earlier, I would claim that increased BC tolerance with opt-in > strictness per file would make it more likely that people use the > latest php version available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
On Sat, 31 Aug 2019 at 03:40, Reindl Harald wrote: > > > > Am 30.08.19 um 20:56 schrieb Andreas Hennings: > > In one of -these modules I initially used the ?? null coalesce operator. > > Then I had to replace all of the instances of ?? with the more verbose > > old-school code, to make it compatible with older PHP, because there > > are still enough Drupal 7 installations out there which have not > > upgraded to PHP 7 yet. > > I also had issues with old 3rd party libraries, which stood in the way > > of PHP version upgrade. > > > > In a world with "editions" per file or per package, such projects > > could more easily use the newest PHP version, while the old libraries > > would continue working. > > no, it could not, when these days installations aren't running PHP7 at > all you won#t have support for new features If "editions" (the way I imagine) had been introduced prior to PHP 7, we might now have a PHP 7 engine that would still support code written for PHP 5.x. There is a limit in how far this makes sense. In a lot of cases, what "breaks" in PHP7 was already broken to begin with. So in a way the BC breaks can be a good thing, they force people to fix the mistakes from the past. > > you can declare what you want on top of the file - when the server is > sloppy mainatined and running stone old software you simply can't use a > recent feature > > just stop supporting such unmaintained setups and they will disappear, > break them as hard as you can! > you need to distinguish two different things here: - server infrastructure / php version. - the actual PHP code in the project, which might be a collection of custom code and various 3rd party packages with different age. upgrading the server infrastructure and php version is easy, compared to upgrading or fixing the PHP code itself. The only reason why people might stick with an old infrastructure and php version is because the new version might break their legacy PHP code. As said earlier, I would claim that increased BC tolerance with opt-in strictness per file would make it more likely that people use the latest php version available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
(I hope this exchange is not getting too Drupal-specific. I imagine the same concerns would apply in any project that uses a lot of 3rd party code, and that is affected by framework versions and generations of framework ecosystems.) > Someone running their code on an old and unsupported PHP version is already, > well, unsupported. This is true, but: - The problem already applies within a range versions that are officially supported at a given time. E.g. the ?? operator came out long before PHP 5.6 became unsupported. At the same time, major Drupal 7 modules had to slowly catch up. And some less popular modules never did. As long as a site was not fully ready for PHP 7.x, developers could not use the ?? operator, or use any 3rd party code that uses the ?? operator. - There might be reasons preventing people from updating. You already agree, so nothing to argue here. > The point, of course, is making that upgrade as much of a no-brainer as > possible so that people have no excuse for not upgrading besides laziness. > That's why there's such a (entirely legitimate) concern for BC breaks, > because every BC break is one more reason for people to not upgrade to a > supported release. absolutely. > Adding new functionality that doesn't break *existing* code is entirely > irrelevant. It's more around subtle changes to existing behavior, which are > sometimes worthwhile and sometimes not. These are two sides to the same coin: - New features which are only available in a new language version. - Old language "features" (or in most cases "bad practices that used to be unpunished") which only work in older PHP versions. Of course this is only a problem if updating or fixing this code would be costly. This creates an interoperability problem between old code (if not fixed or updated) and new code (3rd party or custom), because there is no engine version that allows them to coexist in the same project. Realistically, a large project or ecosystem, like a historic building or a city, will have older and newer parts. Parts you want to touch and work on, and other parts you rather leave alone. For unsupported versions we can always say "your fault", but even within the supported version range there are these interoperability limitations. The trade-off on a specific project might be somewhere in the middle: Use a PHP version that is not the newest but also not the oldest. Fix or update the worst of the legacy code, but avoid new language features until the entire system is ready for it. Of course in the world of technology we cannot expect that a project, or a framework ecosystem, stays around forever. The language version is only one variable in the equation. At some point your framework, or the specific version you are using, will become unsupported. At some point the entire system needs a rewrite, throwing some old stuff out. The "editions" idea (or how I imagine it) would not save you from the need for a periodic rewrite. But it would allow developers to already use the new language features and new 3rd party libraries. So they might already write the code that will later be used in the new rewritten system. E.g. imagine PHP gets generics one day. With "editions" (how I imagine them), you could already use generics in your own custom code, or use composer packages that rely on generics, in your legacy codebase. If you envision a rewrite that relies heavily on generics, you can already develop a lot of this code in the older version of the project. A project which nowadays would run a PHP version somewhere between the oldest and the newest, would now be able to run the latest PHP version most of the time. On Sat, 31 Aug 2019 at 02:31, Larry Garfield wrote: > > On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote: > > On Fri, 30 Aug 2019 at 19:38, Chase Peeler wrote: > > > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings > > > wrote: > > > > The only way to make this possible is to either deny all progress, or > > > > to make a distinction on file level (or "package level", whatever that > > > > means). > > > > So, opt-in BC breaks. > > > > > > > That's not true at all. There are a ton of things that have been discussed > > > that will progress the language and don't require any sort of BC break. > > > Union types is one example. Support for Enums is another. > > > > > > Even if a BC break is required, it's not automatically a bad thing. > > > Whether > > > we are looking at plugging up a big security hole, getting rid > > > of/modifying > > > a rarely used feature, adding support for something that it's currently > > > impossible to do, or just doing something that adds tremendous value to > > > the > > > language. In all of those cases the impact of the BC break should be > > > weighed against the benefits. > > > > The problem and trade-offs I am describing are already impacting me today. > > I am working on a Drupal 7 site with lots of legacy code, and I am > > developing Drupal 7
Re: [PHP-DEV] Bringing Peace to the Galaxy
On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote: > On Fri, 30 Aug 2019 at 19:38, Chase Peeler wrote: > > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings > > wrote: > > > The only way to make this possible is to either deny all progress, or > > > to make a distinction on file level (or "package level", whatever that > > > means). > > > So, opt-in BC breaks. > > > > > That's not true at all. There are a ton of things that have been discussed > > that will progress the language and don't require any sort of BC break. > > Union types is one example. Support for Enums is another. > > > > Even if a BC break is required, it's not automatically a bad thing. Whether > > we are looking at plugging up a big security hole, getting rid of/modifying > > a rarely used feature, adding support for something that it's currently > > impossible to do, or just doing something that adds tremendous value to the > > language. In all of those cases the impact of the BC break should be > > weighed against the benefits. > > The problem and trade-offs I am describing are already impacting me today. > I am working on a Drupal 7 site with lots of legacy code, and I am > developing Drupal 7 contrib modules that I want to be available to a > large audience. > > In one of these modules I initially used the ?? null coalesce operator. > Then I had to replace all of the instances of ?? with the more verbose > old-school code, to make it compatible with older PHP, because there > are still enough Drupal 7 installations out there which have not > upgraded to PHP 7 yet. > I also had issues with old 3rd party libraries, which stood in the way > of PHP version upgrade. > > In a world with "editions" per file or per package, such projects > could more easily use the newest PHP version, while the old libraries > would continue working. That's a somewhat different issue. Someone running their code on an old and unsupported PHP version is already, well, unsupported. They're running code with known unfixed security issues, most likely, and they take their chances. If they won't upgrade to a supported PHP version then, frankly, they're already on their own. The point, of course, is making that upgrade as much of a no-brainer as possible so that people have no excuse for not upgrading besides laziness. That's why there's such a (entirely legitimate) concern for BC breaks, because every BC break is one more reason for people to not upgrade to a supported release. What you're talking about is new language features; well-behaved code written for PHP 5.2 should still run perfectly fine on 7.3, where the ?? operator is quite well supported thank you and if people want to use your new module they should damn well upgrade. (Drupal has had the ability to set a minimum PHP version for a specific module for over a decade; I know, I wrote that functionality. :-) ) > I also had issues with old 3rd party libraries, which stood in the way > of PHP version upgrade. This is the part that is of concern to this discussion. Adding new functionality that doesn't break *existing* code is entirely irrelevant. It's more around subtle changes to existing behavior, which are sometimes worthwhile and sometimes not. Whether editions is the "right" way to balance "don't break 1 million lines of 15 year old code" with "this behavior is bad and we all know it" and with "this behavior leads to sloppy code that is prone to bugs", I don't know. I'm not sure what my stance is on these questions yet. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
On Fri, 30 Aug 2019 at 19:38, Chase Peeler wrote: > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings > wrote: > > The only way to make this possible is to either deny all progress, or > > to make a distinction on file level (or "package level", whatever that > > means). > > So, opt-in BC breaks. > > > That's not true at all. There are a ton of things that have been discussed > that will progress the language and don't require any sort of BC break. > Union types is one example. Support for Enums is another. > > Even if a BC break is required, it's not automatically a bad thing. Whether > we are looking at plugging up a big security hole, getting rid of/modifying > a rarely used feature, adding support for something that it's currently > impossible to do, or just doing something that adds tremendous value to the > language. In all of those cases the impact of the BC break should be > weighed against the benefits. The problem and trade-offs I am describing are already impacting me today. I am working on a Drupal 7 site with lots of legacy code, and I am developing Drupal 7 contrib modules that I want to be available to a large audience. In one of these modules I initially used the ?? null coalesce operator. Then I had to replace all of the instances of ?? with the more verbose old-school code, to make it compatible with older PHP, because there are still enough Drupal 7 installations out there which have not upgraded to PHP 7 yet. I also had issues with old 3rd party libraries, which stood in the way of PHP version upgrade. In a world with "editions" per file or per package, such projects could more easily use the newest PHP version, while the old libraries would continue working. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings wrote: > I would very much like to see "editions" or "generations". > > The only way to make this possible is to either deny all progress, or > to make a distinction on file level (or "package level", whatever that > means). > So, opt-in BC breaks. > > That's not true at all. There are a ton of things that have been discussed that will progress the language and don't require any sort of BC break. Union types is one example. Support for Enums is another. Even if a BC break is required, it's not automatically a bad thing. Whether we are looking at plugging up a big security hole, getting rid of/modifying a rarely used feature, adding support for something that it's currently impossible to do, or just doing something that adds tremendous value to the language. In all of those cases the impact of the BC break should be weighed against the benefits. There have been two proposals recently that have been contentious. Short tag removal and the current RFC for making undeclared variables throw errors. In both cases the arguments against these changes were not just a flat "BC BAD" argument. They all were about the impact of such BC breaks in comparison to what would be gained. In the case of the undeclared variables, it's also being argued that we just shouldn't do it because it gets rid of a feature of the language that some people see as a good feature. To paint either one of them as an indication that we can't every do anything that causes a BC break is just flat out false. I'm not saying what you are proposing here is good or bad. I just wanted to comment on this particular assertion because I've seen others make such statements as well, and all they do is cause further division and animosity. It shifts debate from the merits of a particular issue or RFC to more abstract levels, where both sides paint the other in absolute terms that aren't close to valid. > To me the "file level" seems most realistic. > If someone can make a convincing point of what "package level" would > mean technically, why not. > I just think that "package" is not a clearly defined term, and often > all you have is a file (e.g. with symlink, or when downloading a file > from some place). > And sometimes you might want different versions / generations in the > same package. > My first reply got rejected by the listserv for being too big. I cleaned up some the quoted text, but I apologize if anyone sees this twice. Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] Bringing Peace to the Galaxy
I would very much like to see "editions" or "generations". > I do plan to create an RFC on this topic. I am looking forward to this Proposal from Nikita. So, at the risk of repeating some ideas that Nikita already mentioned elsewhere, I am sharing my own thoughts.. ## Motivation In this mailing list, it often comes across as if BC support vs "modernizing" the language is a matter of personal preference. The reality is: After a given time, a complex PHP project (whether it be a website or something else) will be a collection of old and new, custom and 3rd party code. The same applies to framework ecosystems, or the entire ecosystem of 3rd party libraries (in composer/packagist and elsewhere). As a (website) project developer: - I want to use the newest tricks of the language, and have the strictest warnings possible, in new custom code. - I want to pick from a wide variety of (old and new) 3rd party libraries. - I don't want to be forced to update or replace legacy 3rd party libraries, that might have been added before I even joined the project, and I have no idea what they do. - I don't want to be forced to fix old legacy custom code, of which I don't know what it does. Or rather, I want to choose when to do this based on the project life cycle. - After phases of active development, I want to be able to put the site in a mode where it "just works", until the client wants a major revamp. - I want the project to run on different local and server environments, possibly sharing the space with other projects. As a library/packge developer: - I want to use the newest tricks of the language, and have the strictest warnings possible, in new code. - I want my library to be compatible with a wide audience with different PHP versions. Existing projects should have the option to include my library without throwing away or revamping all their old stuff. - If developing within a framework ecosystem (e.g. Drupal), I want my library to be compatible with other packages in the same ecosystem, and the PHP version(s) most commonly used within that ecosystem. - After a phase of active development on (a major version of) the package, I want the package (or that major version) to turn into a low-maintenance mode, and focus either on the new major version, or on other things in life. People should be able to use the aging package without major disruption. As a PHP language designer (which I cannot claim to be, but doing it anyway): - I want modern PHP to be a "competitive" language. - At the same time I want PHP to maintain the reputation of being a stable and reliable platform for existing projects. - I want a continuous, incremental evolution of the language, with one change at a time, to allow for sufficient discussion and not lose the community. - I want to allow for future changes which I cannot even dream of today. So I constantly want to "have my cake and eat it, too". Not based on personal preference, but on real-world requirements. ## Proposal / Idea The only way to make this possible is to either deny all progress, or to make a distinction on file level (or "package level", whatever that means). So, opt-in BC breaks. To me the "file level" seems most realistic. If someone can make a convincing point of what "package level" would mean technically, why not. I just think that "package" is not a clearly defined term, and often all you have is a file (e.g. with symlink, or when downloading a file from some place). And sometimes you might want different versions / generations in the same package. This would mean: - A PHP file can specifiy the "generation" or "edition" or simply the version of PHP that it claims to be compatible with. One (perhaps silly) idea would be to have an alternative open tag like " wrote: > > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote: > > > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote: > > > >> [... and not in the Sith Lord kind of way.] > >> > >> Looking at some of the recent (& not so recent) discussions on internals@ > >> , > >> some of the recent proposals, as well as some of the statements made > >> regarding the future direction of the language - makes it fairly clear > >> that > >> we have a growing sense of polarization. > >> > >> As Peter put it yesterday (I may be paraphrasing a bit) - some folks just > >> want to clear some legacy stuff. I think that in practice it goes well > >> beyond that - many on internals@ see parts of PHP as in bad need of > >> repair > >> (scoop: I agree with some of that), while other capabilities, that exist > >> in > >> other competing languages - are - in their opinion - sorely missing. > >> > >> At the other end of the spectrum, we have folks who think that we should > >> retain the strong bias for downwards compatibility we always had, that PHP > >> isn't in dire need of an overhauling repair and that as far as features go > >> - less is more - and we don't have to race to replicate features from > >> other > >> languages -
Re: [PHP-DEV] Make error_reporting=E_ALL the default
Hello, On Fri, 30 Aug 2019 at 13:51, G. P. B. wrote: > > On Fri, 30 Aug 2019 at 11:45, Zeev Suraski wrote: > > > > > > On 30 Aug 2019, at 12:33, Nikita Popov wrote: > > > > > > Hi internals, > > > > > > Relating to the recent discussions on undefined variables & co. One thing > > > that is particularly annoying about the undefined variable case is that > > our > > > default error_reporting level (without a php.ini) does not include > > E_NOTICE. > > > > > > Thankfully distros do tend to have more reasonable defaults, but if you > > > spend as much time with custom PHP builds as I do, not seeing *anything* > > > for undefined variables is a pretty big annoyance. > > > > > > Does anyone see an issue with making error_reporting=E_ALL the default in > > > PHP 8? It can of course still be manually downgraded via php.ini and > > > php.ini-production will retain the existing recommendation that excludes > > > E_DEPRECATED/E_STRICT. > > > > > > PR: https://github.com/php/php-src/pull/4659 > > > > By the way - I'd consider going a bit further than that, and re-sync our > > internal defaults with the values of php.ini-development. In the past - > > when we had -dist and -recommended - the intended behavior was that having > > php.ini-dist as your php.ini would be identical to not having a php.ini > > file at all. I think it can be useful if we do the same for > > php.ini-development (by changing the internal defaults to correspond to it > > of course, not the other way around) instead of having to agree > > individually on each change. For the future, agreeing on a change in > > php.ini-development would directly imply changing the internal defaults. > > > > Zeev > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > I'm not sure we can totally execute on that otherwise we would need to > change the default of the short_tag directive, which from my understanding > was one of the pain points of the Short Tag RFC. > Other than that I wholeheartedly agree that syncing the dev one with the > defaults would be a good idea but then I'm not totally sure what it's point > *would* be. > > Best regards > > George P. Banyard About the error_reporting, I always set this to E_ALL for all environments also, yes. Syncing with the php.ini-production would probably make more sense because there are production environments that might not use any ini files (a bit of an edge case but when developing adding ini file seems more natural and secure than the other way around I think). The short opening tags ini directive of course will now stay different than the PHP internal default. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make error_reporting=E_ALL the default
On Fri, 30 Aug 2019 at 11:45, Zeev Suraski wrote: > > > On 30 Aug 2019, at 12:33, Nikita Popov wrote: > > > > Hi internals, > > > > Relating to the recent discussions on undefined variables & co. One thing > > that is particularly annoying about the undefined variable case is that > our > > default error_reporting level (without a php.ini) does not include > E_NOTICE. > > > > Thankfully distros do tend to have more reasonable defaults, but if you > > spend as much time with custom PHP builds as I do, not seeing *anything* > > for undefined variables is a pretty big annoyance. > > > > Does anyone see an issue with making error_reporting=E_ALL the default in > > PHP 8? It can of course still be manually downgraded via php.ini and > > php.ini-production will retain the existing recommendation that excludes > > E_DEPRECATED/E_STRICT. > > > > PR: https://github.com/php/php-src/pull/4659 > > By the way - I'd consider going a bit further than that, and re-sync our > internal defaults with the values of php.ini-development. In the past - > when we had -dist and -recommended - the intended behavior was that having > php.ini-dist as your php.ini would be identical to not having a php.ini > file at all. I think it can be useful if we do the same for > php.ini-development (by changing the internal defaults to correspond to it > of course, not the other way around) instead of having to agree > individually on each change. For the future, agreeing on a change in > php.ini-development would directly imply changing the internal defaults. > > Zeev > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php I'm not sure we can totally execute on that otherwise we would need to change the default of the short_tag directive, which from my understanding was one of the pain points of the Short Tag RFC. Other than that I wholeheartedly agree that syncing the dev one with the defaults would be a good idea but then I'm not totally sure what it's point *would* be. Best regards George P. Banyard
Re: [PHP-DEV] Make error_reporting=E_ALL the default
+1 On Fri, Aug 30, 2019, 11:13 AM Javier Spagnoletti wrote: > Great step! +1 > Thank you so much Nikita. > > El vie., 30 de ago. de 2019 07:02, Arvids Godjuks < > arvids.godj...@gmail.com> > escribió: > > > пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > > > > > Hi internals, > > > > > > Relating to the recent discussions on undefined variables & co. One > thing > > > that is particularly annoying about the undefined variable case is that > > our > > > default error_reporting level (without a php.ini) does not include > > > E_NOTICE. > > > > > > Thankfully distros do tend to have more reasonable defaults, but if you > > > spend as much time with custom PHP builds as I do, not seeing > *anything* > > > for undefined variables is a pretty big annoyance. > > > > > > Does anyone see an issue with making error_reporting=E_ALL the default > in > > > PHP 8? It can of course still be manually downgraded via php.ini and > > > php.ini-production will retain the existing recommendation that > excludes > > > E_DEPRECATED/E_STRICT. > > > > > > PR: https://github.com/php/php-src/pull/4659 > > > > > > Regards, > > > Nikita > > > > > > > +1 from userland. > > > > I always have edited the php.ini for production. I also usually edit > > development too to include all error levels, but yeah - having shipped > > php.ini with sane defaults would be very welcome. > > I do agree with Zeev that production file should probably resemble what > > php.ini-development is right now, so I'd say we need to go deeper ;) > > > > -- > > Arvīds Godjuks > > > > +371 26 851 664 > > arvids.godj...@gmail.com > > Skype: psihius > > Telegram: @psihius https://t.me/psihius > > >
Re: [PHP-DEV] Make error_reporting=E_ALL the default
Great step! +1 Thank you so much Nikita. El vie., 30 de ago. de 2019 07:02, Arvids Godjuks escribió: > пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > > > Hi internals, > > > > Relating to the recent discussions on undefined variables & co. One thing > > that is particularly annoying about the undefined variable case is that > our > > default error_reporting level (without a php.ini) does not include > > E_NOTICE. > > > > Thankfully distros do tend to have more reasonable defaults, but if you > > spend as much time with custom PHP builds as I do, not seeing *anything* > > for undefined variables is a pretty big annoyance. > > > > Does anyone see an issue with making error_reporting=E_ALL the default in > > PHP 8? It can of course still be manually downgraded via php.ini and > > php.ini-production will retain the existing recommendation that excludes > > E_DEPRECATED/E_STRICT. > > > > PR: https://github.com/php/php-src/pull/4659 > > > > Regards, > > Nikita > > > > +1 from userland. > > I always have edited the php.ini for production. I also usually edit > development too to include all error levels, but yeah - having shipped > php.ini with sane defaults would be very welcome. > I do agree with Zeev that production file should probably resemble what > php.ini-development is right now, so I'd say we need to go deeper ;) > > -- > Arvīds Godjuks > > +371 26 851 664 > arvids.godj...@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius >
Re: [PHP-DEV] Make error_reporting=E_ALL the default
пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include > E_NOTICE. > > Thankfully distros do tend to have more reasonable defaults, but if you > spend as much time with custom PHP builds as I do, not seeing *anything* > for undefined variables is a pretty big annoyance. > > Does anyone see an issue with making error_reporting=E_ALL the default in > PHP 8? It can of course still be manually downgraded via php.ini and > php.ini-production will retain the existing recommendation that excludes > E_DEPRECATED/E_STRICT. > > PR: https://github.com/php/php-src/pull/4659 > > Regards, > Nikita > +1 from userland. I always have edited the php.ini for production. I also usually edit development too to include all error levels, but yeah - having shipped php.ini with sane defaults would be very welcome. I do agree with Zeev that production file should probably resemble what php.ini-development is right now, so I'd say we need to go deeper ;) -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Make error_reporting=E_ALL the default
> On 30 Aug 2019, at 12:33, Nikita Popov wrote: > > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include E_NOTICE. > > Thankfully distros do tend to have more reasonable defaults, but if you > spend as much time with custom PHP builds as I do, not seeing *anything* > for undefined variables is a pretty big annoyance. > > Does anyone see an issue with making error_reporting=E_ALL the default in > PHP 8? It can of course still be manually downgraded via php.ini and > php.ini-production will retain the existing recommendation that excludes > E_DEPRECATED/E_STRICT. > > PR: https://github.com/php/php-src/pull/4659 By the way - I'd consider going a bit further than that, and re-sync our internal defaults with the values of php.ini-development. In the past - when we had -dist and -recommended - the intended behavior was that having php.ini-dist as your php.ini would be identical to not having a php.ini file at all. I think it can be useful if we do the same for php.ini-development (by changing the internal defaults to correspond to it of course, not the other way around) instead of having to agree individually on each change. For the future, agreeing on a change in php.ini-development would directly imply changing the internal defaults. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make error_reporting=E_ALL the default
> On 30 Aug 2019, at 12:33, Nikita Popov wrote: > > Hi internals, > > Relating to the recent discussions on undefined variables & co. One thing > that is particularly annoying about the undefined variable case is that our > default error_reporting level (without a php.ini) does not include E_NOTICE. > > Thankfully distros do tend to have more reasonable defaults, but if you > spend as much time with custom PHP builds as I do, not seeing *anything* > for undefined variables is a pretty big annoyance. > > Does anyone see an issue with making error_reporting=E_ALL the default in > PHP 8? It can of course still be manually downgraded via php.ini and > php.ini-production will retain the existing recommendation that excludes > E_DEPRECATED/E_STRICT. > > PR: https://github.com/php/php-src/pull/4659 +1 Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Make error_reporting=E_ALL the default
Hi internals, Relating to the recent discussions on undefined variables & co. One thing that is particularly annoying about the undefined variable case is that our default error_reporting level (without a php.ini) does not include E_NOTICE. Thankfully distros do tend to have more reasonable defaults, but if you spend as much time with custom PHP builds as I do, not seeing *anything* for undefined variables is a pretty big annoyance. Does anyone see an issue with making error_reporting=E_ALL the default in PHP 8? It can of course still be manually downgraded via php.ini and php.ini-production will retain the existing recommendation that excludes E_DEPRECATED/E_STRICT. PR: https://github.com/php/php-src/pull/4659 Regards, Nikita
