Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101800
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CALKiJKrwQLOSnJVTZE6z9Va_wCvLOvaocjPjMmw+cdyj3+JK8w@mail.gmail.com>
References: <CAOv67gvh_TM8B+ZvJeMwQDN7wnC+n7JiW78Ydk+V3wRjsXigBA@mail.gmail.com>
 <CALKiJKrwQLOSnJVTZE6z9Va_wCvLOvaocjPjMmw+cdyj3+JK8w@mail.gmail.com>
Date: Wed, 7 Feb 2018 09:26:33 -0700
Message-ID: <CAFMT4Np8utnEa5XyPHCuT5J3EnP7cmgeZg3DSOv7eFvGGqgMjQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: 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 Wed, Feb 7, 2018 at 7:02 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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]

My opinion is that the result is both uglier and *even less
consistent* with namespaced types. I'm glad you are at least thinking
about alternative proposals but this is worse than both the original
proposal and doing nothing.