Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101798
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
In-Reply-To: <CAOv67gvh_TM8B+ZvJeMwQDN7wnC+n7JiW78Ydk+V3wRjsXigBA@mail.gmail.com>
References: <CAOv67gvh_TM8B+ZvJeMwQDN7wnC+n7JiW78Ydk+V3wRjsXigBA@mail.gmail.com>
Date: Wed, 7 Feb 2018 14:02:34 +0000
Message-ID: <CALKiJKrwQLOSnJVTZE6z9Va_wCvLOvaocjPjMmw+cdyj3+JK8w@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045c143e461af805649fbfe4"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
From: rowan.collins@gmail.com (Rowan Collins)

--f403045c143e461af805649fbfe4
Content-Type: text/plain; charset="UTF-8"

On 3 February 2018 08:27:18 GMT+00:00, Wes <netmo.php@gmail.com> wrote:
>Hello PHPeople. I just published the RFC "Deprecation of fallback to
>root
>scope".
>
>https://wiki.php.net/rfc/fallback-to-root-scope-deprecation


Given the discussion so far, how about taking the "opposite" approach:
deprecate unprefixed reference to functions which *are* in the current
namespace.

Proposal:
- PHP 7.3: Add syntax to explicitly reference functions and constants in
the current namespace, such as .\foo or this\foo
- PHP 7.4: Raise E_DEPRECATED whenever an unprefixed function/constant
resolves to something in the current namespace (other than via "use" alias)
- PHP 8.0: Make all unprefixed functions/constants always refer to the root
namespace

Pros:
- Much less disruptive change, as the majority of unprefixed function calls
are to global functions, and would not need to change.
- Both cases can be made unambiguous if the author wants to.
- Apparently OpCache currently mitigates the performance hit by caching
lookups in a technically unclean way. Users hit by this can make their code
unambiguous in 7.3, and the optimisation will become clean in 8.0.
- Function / constant autoloading can be added in 7.x if we accept the
caveat that unprefixed functions will not be autoloaded; or in 8.0 if we
want to cover everything.

Cons:
- Slightly uglier syntax.
- Still a breaking change (in 8.0).
- Class names will still be resolved differently from function and constant
names.
- Code actively using the fallback system (e.g. tests masking global
functions with mocks) will need refactoring as there is no way to opt into
the old behaviour.
- The .\foo() syntax may appear in similar places to the . concatenation
operator. Even if technically unambiguous and implementable in the parser,
this may be confusing to users. A keyword approach like this\foo() would be
clearer, but more verbose.

What do people think? Is it worth expanding this out into an alternative
RFC?

Regards,
-- 
Rowan Collins [IMSoP]

--f403045c143e461af805649fbfe4--