Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101779
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAEPJdu=SBAJiPf-jP27ViQJ=Rk4fk5m841L8=LhBa9HtScdSPA@mail.gmail.com>
References: <CAOv67gvh_TM8B+ZvJeMwQDN7wnC+n7JiW78Ydk+V3wRjsXigBA@mail.gmail.com>
 <CAEPJdunk-uWhaqOtUP24qNzqv-EBvJnJncikPsfLBtjPkfwH8g@mail.gmail.com>
 <07d9e3a0-d516-aa77-4818-ce8b02e8dd08@gmail.com> <CAEPJdu=SBAJiPf-jP27ViQJ=Rk4fk5m841L8=LhBa9HtScdSPA@mail.gmail.com>
Date: Mon, 5 Feb 2018 18:51:51 -0700
Message-ID: <CAFMT4Nqz6Tdr3cGvoU2_k_dTRNcTiuqL--mkA26LeGwCjb6=tw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Wes <netmo.php@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
From: levim@php.net (Levi Morrison)

On Mon, Feb 5, 2018 at 9:54 AM, Benjamin Eberlei <kontakt@beberlei.de> wrote:
> On Sun, Feb 4, 2018 at 10:56 PM, Stanislav Malyshev <smalyshev@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.