Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <79b192e6-a6bd-bd13-6bd4-b56011a5eac2@gmx.de>
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>
Date: Mon, 5 Feb 2018 08:28:39 -0600
Message-ID: <CAEUnE0daTFOHSwKBeHatqxbMaX4K8-VgdcD4dmxsxAQ9N4TOeQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c188268dcb441056477e02a"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
From: tendoaki@gmail.com (Michael Morris)

--94eb2c188268dcb441056477e02a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

May I propose a compromise?

If I understand what I've read over, the default of functions and constants
to global scope is the primary blocking issue for creating an autoloader
for these elements. Where that not PHP's behavior this functionality could
have been implemented by now.

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.

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.

This solution isn't perfect.  From where Drupal stands, even if all it's
own code stopped using global functions the packages it relies on likely
will continue to do so for some time. Even if they don't, there may be
compatibility issues with the newer version.

A slightly better solution would be to allow this to be set on a per
namespace basis, but as PHP has no true notion of a namespace I don't think
this can be implemented.  The declare() statement might allow it to be done
on a per file basis, but that's going to get messy fast.

Still, I feel it is a workable approach despite the drawbacks.  If anything
this problem highlights another problem elsewhere in PHP - the inability to
isolate package configuration, or configure packages at all.  But that's a
topic for another RFC, one I won't be starting cause I have no idea how to
fix it.

On Mon, Feb 5, 2018 at 8:09 AM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 04.02.2018 at 22:56, Stanislav Malyshev wrote:
>
> >> 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, [=E2=80=A6]
>
> Do we?  AFAIK, it is not possible to import *all* functions (or even all
> symbols, for that matter) of a namespace, without explicitly mentioning
> them.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c188268dcb441056477e02a--