On Mon, Feb 5, 2018 at 9:54 AM, Benjamin Eberlei <kont...@beberlei.de> wrote: > On Sun, Feb 4, 2018 at 10:56 PM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > >> Hi! >> >> > To get the same benefits (jit and such) wouldn't it be better to >> introduce >> > a "use function root;" or similar statement or a declare() to specify >> this >> > file imports all root functions? >> >> We already have this right now, and realistically speaking, who wouldn't >> do that in their code instead of writing weird \strlen() code? Everybody >> would configure their IDEs and so to insert this automatically. So we're >> talking about RFC to make people work harder for what they already have >> now and then end up in the same place we are already right now. >> > > Yes we do have root namespace lookup, but its not automatic, it is only as > a fallback. This RFC is about removing the intermediate namespace'd check, > hence requiring \strlen. > > My idea was to force all function lookups into the global nameespace first > by doing the declare or use. This way someone writing a file could state "i > dont use namespaced functions in this file, don't try to load them". > > I agree its annoying and more work, just wanted to present it as an > alternative option. > > >> >> > was acted on at any time in the future. and in addition people will >> silence >> > the notices on global error reporting level, because violations would >> >> And note also that we can't silence just this warning. Which means >> people would have to silence *all* warnings, thus making all other >> messages useless. This is not a good development and this is not what we >> should be training users to do - saying "well, it's a warning, just >> silence it" is the worth idea we could have. If we create a warning, >> recommendation should be "it's important enough so we call your >> attention to it, please deal with it", not "just silence it". If it's OK >> in most cases (as opposed to rare exceptional cases) for it to be >> silenced, it shouldn't be there in the first place. >> > > Yes, this is why I have a problem with using E_STRICT (we don't have a lot > of them at the moment, but maybe in preparation of 8 more?) warning for it. > It would send a wrong signal to ignore rather than fix, because the amount > of violations would be massive.
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. If we are uncomfortable removing this feature in PHP 8.0 that means support would extend until the end of the last PHP 8 release. My best guess is that is at least 5 more years but probably more. That puts us in the 10-12 years timeframe. If we cannot fix such an issue *over an entire decade* then we may as well call PHP 7 the last major release. And let me be clear: I would like there to be a PHP 8 and a PHP 9. I think most of our users would like that as well. This means we have breaking to do over the next decade. The responsible thing is to give users this information as early as possible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
