On Tuesday, February 6, 2018 4:08:03 AM CST Rowan Collins wrote: > On 6 February 2018 at 01:51, Levi Morrison <le...@php.net> wrote: > > It's fine to ignore them as long as they fix them later. That's > > precisely why I think E_STRICT is a good category for these notices. > > If, however, they ignore them forever that's their fault; we are > > simply providing advanced notice of a behavior we'd like to eventually > > change. > > > > Let me put "eventually" into perspective. We will probably have a 7.3 > > before we have an 8.0. This means that 8.0, the absolute earliest > > version we could remove this feature, is at least 2 years away before > > it reaches *any* of our users. Unless we extend it like we did with > > the last 5.X release (and I think we probably should extend it) this > > means that users can run their existing code on an officially > > supported PHP 7 release for the next 4 years at the minimum. I am > > fairly confident that for one reason or another it will delay another > > year or two, putting it at 5-6 years. > > I think for a lot of people the "forever" in your first paragraph and the > "5-6 years" in your second paragraph will feel like the same thing. If the > message is "this might be removed some time in the next decade", people > will simply shrug and ignore it until an actual removal is announced; > thinking as a cynical user, there's no guarantee the recommendation won't > be changed back in future - we've had features "undeprecated" before. > > As others have pointed out, even if you run an analyser over your own code > base to add \ in the appropriate places, you can't turn on E_STRICT notices > without being flooded until all your dependencies have done the same - and > there's no compelling reason for them to do so. > > 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. > > Regards,
Potential benefits of this change aside, I have to agree with Rowan on tactics. A carrot works much better than a stick in this case. Remember also that many larger systems stay around and in production WAAAAAAAAAAAAY past their expected lifetimes; there are still poor souls running PHP 4, and I personally know of Drupal 5 sites still in the wild. So even if the HEAD version of everything is updated within a year for such a change the long tail of what's running out in the world will lag badly. That said, I'm not sure that function autoloading will be that big of a carrot for the major projects at this point. Wordpress is going to ignore anything we do here anyway for at least 15 years, and pretty much every other project in existence has gone all-OOP or nearly-all-OOP at this point (good or bad is beside the point). Namespaced user defined functions are rare in my experience outside of very specific libraries (such as functional tooling libs). So "yay, you can now autoload namespaced user-defined functions" will likely be met with a lot of "what are those?" --Larry Garfield
signature.asc
Description: This is a digitally signed message part.
