Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101769
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6sJ2eVtcetD1QG9rBSek4ZEBZYEhNdBd+7C=7EqywH7daQ@mail.gmail.com>
References: <CAOv67gvh_TM8B+ZvJeMwQDN7wnC+n7JiW78Ydk+V3wRjsXigBA@mail.gmail.com>
 <59e48427-ce88-58fb-f802-48b7412e480d@hoa-project.net> <CADyq6sJ2eVtcetD1QG9rBSek4ZEBZYEhNdBd+7C=7EqywH7daQ@mail.gmail.com>
Date: Mon, 5 Feb 2018 12:52:04 +0000
Message-ID: <CALKiJKo=m0+jpcQCtwgsKUiYOs-L82waTQ+yzHQN130Y78DTTg@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c1af74a7801500564768781"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
From: rowan.collins@gmail.com (Rowan Collins)

--94eb2c1af74a7801500564768781
Content-Type: text/plain; charset="UTF-8"

On 5 February 2018 at 10:53, Marco Pivetta <ocramius@gmail.com> wrote:

>
> See https://externals.io/message/101745#101752
>
> The problem is always with routines (not  functions)) that rely on shared
> global mutable state.
>
> Mocking those is generally a problem, as it exposes a dependency inversion
> issue, rather than actually getting rid of an implicit reliance on global
> state that is not declared to consumers of a SUT.
>

While that would be a perfectly fine justification for not adding this
feature, it doesn't address the impact of removing the feature now that it
has existed for over 8 years. Even before the feature is actually removed,
anyone using such tests would be faced with the following options:

* Put up with hundreds of notices until they have a chance to completely
refactor the code in question.
* Suppress all messages of a particular level (possibly E_STRICT initially
and E_DEPRECATED later) until they have the chance to refactor.
* Prepend \ to global function references, purely to stop the deprecation
notices, and break all tests that relied on this mocking mechanism.

None of these options is particularly appealing, and this will all be for a
hypothetical future improvement to the language.

Regards,
-- 
Rowan Collins
[IMSoP]

--94eb2c1af74a7801500564768781--