I think we should distinguish two separate problems in the discussion: 1. Undeclared local variables in function scope. Some poeple here think this "lazy" way of coding is actually more productive.
Fixing such places would be straightforward.. except that it may require patching some legacy 3rd party code. 2. Undeclared values, or values of unexpected type, in variables coming from elsewhere: - variables used in file scope, e.g. in template files, which are declared in a different file. - any global variables. - values in nested arrays, which might have been set in some other place before they get passed to the current function. Typically these cases are hard to fix and troubleshoot. Especially, even if you think you fixed it, there can be some dynamic conditions that are really hard to test. E.g. if the username begins with a capital letter, the variable will be undefined, or a specific array value will be an object instead of a string.. Ideally such systems should be avoided, or they will need a lot of try/catch to deal with such problems in the future. But a lot of legacy code was not written with sufficient sanity checks, and accepts the occasional or regular notice. Perhaps is about time for this level of breakage in PHP8. I just want us to be aware of it. On Sat, 31 Aug 2019 at 05:23, Thomas Bley <ma...@thomasbley.de> wrote: > > That's a good point, maybe a compromise is this: > > <?php // php latest > <?php7 // old behaviour > > That way new users can always use <?php, maintainers for old code bases can > quickly patch the code with <?php7 to force the old way of engine warnings. I am not sure about all the possible implications of this specific syntax, but I think it would fit into the "editions" idea from the other thread, if I am not misunderstanding Nikic. > > Regards > Thomas > > > Matthew Brown <matthewmatt...@gmail.com> 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 <ma...@thomasbley.de> 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. yes.. > > > 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 <matthewmatt...@gmail.com> 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 <rowan.coll...@gmail.com> > > > > > wrote: > > > > > On 28 August 2019 15:22:22 BST, Matthew Brown > > > > > <matthewmatt...@gmail.com> > > > > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
