Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107883
MIME-Version: 1.0
References: <DM6PR07MB45536166C2939FF19F496893F9440@DM6PR07MB4553.namprd07.prod.outlook.com>
 <CALKiJKo3eeyM51AB0o+nph2WfkNWaJ8tQp1h23ETencJXzE+Dw@mail.gmail.com> <CC8451BD-8425-41F4-A5E2-8BF66296B57E@gmail.com>
In-Reply-To: <CC8451BD-8425-41F4-A5E2-8BF66296B57E@gmail.com>
Date: Thu, 28 Nov 2019 11:56:53 +0000
Message-ID: <CALKiJKp4VoaiWW0i=8HGTxxS9xbyhX0Mkc034AQmhD8NGDN5SA@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d63b2d059866cfe8"
Subject: Re: [PHP-DEV] Opt-in "use function *;" for skipping check for
 function/const in alternate namespace
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000d63b2d059866cfe8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 28 Nov 2019 at 11:01, Claude Pache <claude.pache@gmail.com> wrote:
> I think it is better to keep the language as regular as possible, and
consider that every non-fully-qualified name is relative to the current
namespace, unless there is an explicit `use` declaration that says otherwis=
e

That's already false, and will only be true if we deprecate and remove the
fallback to global scope.


> use function *; // don't know what this does, but apparently it's good fo=
r
> > performance =C2=AF\_(=E3=83=84)_/=C2=AF
>
> Or: =E2=80=9Cdon't know what this does, but apparently it silences deprec=
ation
> notices...=E2=80=9D
>


Silencing deprecation notices is always a temporary side-effect of fixing
code to work *at all* in some future release. Or rather, it should be - I
am 100% against any notion of "indefinitely deprecated and may never be
removed", that should always be some other type of notice.

If we were deprecating unqualified functions from being looked up in the
current namespace, we would not need to add this new directive, we could
raise deprecation notices whenever the current lookup logic succeeded in
finding a namespaced function. Silencing the deprecation notice would
require either fully qualifying the function name, or explicitly adding a
"use" statement.



The issue indeed is that the meaning is far from self-evident. Maybe one
> could use something that everyone and their mother could understand at
> first reading, such as:
>
> use function from global namespace;
>


That still doesn't really explain what's happening, because in code that
doesn't use any namespaced functions, the line has no user-visible effect
at all - functions are *always* used from the global namespace. What it
actually does is switch *off* a language feature, so perhaps it should be
something more like:

declare(lookup_functions_in_current_namespace=3Dfalse);

That would also mean that it can be covered by any future way of setting
language directives, such as settings per "module", bundling into
"editions", etc.

Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000d63b2d059866cfe8--