On 6 February 2018 at 14:36, Levi Morrison <le...@php.net> wrote: > > That's why I think having some concrete benefit much sooner is the only > way > > to stop people resenting this change. Build function autoloading in a way > > that it only works if you opt out of the fallback, and *then* deprecate > the > > fallback mode, and it feels like progress rather than disruptive > tinkering. > > This thinking is too pessimistic. We cannot design to appease our > worst users. The advanced notice is better than a sudden one even if > we have function autoloading. >
Perhaps I wasn't clear; I'm not saying the transition should be more sudden, I'm just saying that we should introduce an opt-in advantage alongside the flood of messages. As I understand it, the timeline you support is: * Raise E_STRICT in PHP 7.3. * Once we have a plan to actually change the behaviour, move to E_DEPRECATED, e.g. in PHP 7.5, or 8.0. * Remove fallback at the same time as introducing autoloading, in PHP 8.0 or maybe 9.0. The timeline I am suggesting is: * Add an opt-in feature which enables some advantage, probably autoloading, as soon as possible, e.g. PHP 7.3 or 7.4 * Raise E_DEPRECATED for code which doesn't opt in and doesn't fully-qualify function names, once usage is established, e.g. PHP 7.5, or 8.0 * Remove the fallback mode as a purely internal change, in PHP 8.0 or 9.0. People would still be changing code on much the same timeline, but we wouldn't have the long period of telling people to change all their code without any benefit to them or us. I also think it's a stretch to call people affected by this change "our worst users". I don't know if any common coding standards cover leading backslashes (I searched the PSR-12 draft and Drupal style guide and neither seems to mention it) but if they do, they're as likely to say "never add them" as "always add them", particularly given their use as a hack to "mock" global functions. Or perhaps by "worst users" you mean "users not willing to change their code" - in which case remember that this is a disruptive and risky change to an entire code base for no immediate benefit; putting off such a change might be a perfectly rational decision. Regards, -- Rowan Collins [IMSoP]
