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
