Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101776
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEUnE0d=CJ=4-ggiMLvSFtFMjwz7JkSG5Dv6jeNBtQdtGAozXA@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> <79b192e6-a6bd-bd13-6bd4-b56011a5eac2@gmx.de>
 <CAEUnE0daTFOHSwKBeHatqxbMaX4K8-VgdcD4dmxsxAQ9N4TOeQ@mail.gmail.com>
 <CADyq6sJ9dLRUU-fdj_kB++4GjvLW85Q=K5oRWcUEb2+SUt4siQ@mail.gmail.com> <CAEUnE0d=CJ=4-ggiMLvSFtFMjwz7JkSG5Dv6jeNBtQdtGAozXA@mail.gmail.com>
Date: Mon, 5 Feb 2018 15:43:04 +0100
Message-ID: <CADyq6s+oQbe7Y_k6rCSsjjRg3K2SpGeWt-sVy5eOQvjbmSfjDQ@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="089e082f86089fbf780564781528"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
From: ocramius@gmail.com (Marco Pivetta)

--089e082f86089fbf780564781528
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 5, 2018 at 3:39 PM, Michael Morris <tendoaki@gmail.com> wrote:

>
>
> On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta <ocramius@gmail.com> wrote:
>
>>
>> On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris <tendoaki@gmail.com>
>> wrote:
>>
>>> The problem is that behavior has been around so long that any attempt to
>>> change it would incur a massive amount of changes. Using the E_STRICT
>>> notice level instead of E_DEPRECATED has been floated as one fix for
>>> this,
>>> but this doesn't change the fact that major applications and frameworks,
>>> such as Drupal, pride themselves in being able to pass all tests even
>>> with
>>> E_STRICT enabled. The maintainers of these projects would be annoyed to
>>> say
>>> the least to need to fix thousands of lines of code to get back to that
>>> point, and downstream projects such as Drupal could end up waiting years
>>> for all their upstream libraries to get their act together.
>>>
>>
>>  Much like any upgrade requiring patches for full compliance with newer
>> PHP versions, it needs work.
>>
>> The typical workflow is:
>>
>>  * add PHP.NEXT to the CI setup
>>  * run everything through the tests again, figure out how much has broken
>>  * fix it
>>
>> In this case, we even *already* have *multiple* tools that automatically
>> fix this problem in one shot.
>>
>> Since the two issues are somewhat tied, why not bind them to a
>>> configuration flag following the pattern that was used to ultimately
>>> remove
>>> register_globals functionality from the language?  At this point let it
>>> be
>>> known that when constant/function overloaders hit a php.ini config option
>>> will be added to turn them on -- and turning them on will turn global
>>> scoping for functions off.
>>>
>>
>> Argh
>>
>>
> Agreed, but you can't just pull the rug out from under people. It's
> painful, but it's better to let people opt in to such a major change than
> to "break" their code.
>

We're talking about a deprecation, not removal of a feature.

First of all, it doesn't remove the feature, which means that everything
keeps working as-is, and second, we already have a way to configure error
reporting for deprecations ("configuration") ;-)

The point of deprecations is precisely to give downstream time to adjust
and release the adapted code, which we do all the time anyway.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--089e082f86089fbf780564781528--