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. 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. > > 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
