Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107884
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CALKiJKp4VoaiWW0i=8HGTxxS9xbyhX0Mkc034AQmhD8NGDN5SA@mail.gmail.com>
Date: Thu, 28 Nov 2019 14:19:00 +0100
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D0689A24-8F0F-498B-ACF4-55CA1C82FDF2@gmail.com>
References: <DM6PR07MB45536166C2939FF19F496893F9440@DM6PR07MB4553.namprd07.prod.outlook.com>
 <CALKiJKo3eeyM51AB0o+nph2WfkNWaJ8tQp1h23ETencJXzE+Dw@mail.gmail.com>
 <CC8451BD-8425-41F4-A5E2-8BF66296B57E@gmail.com>
 <CALKiJKp4VoaiWW0i=8HGTxxS9xbyhX0Mkc034AQmhD8NGDN5SA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Opt-in "use function *;" for skipping check for
 function/const in alternate namespace
From: claude.pache@gmail.com (Claude Pache)



> Le 28 nov. 2019 =C3=A0 12:56, Rowan Tommins <rowan.collins@gmail.com> =
a =C3=A9crit :
>=20
> 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 =
otherwise
>=20
> That's already false, and will only be true if we deprecate and remove =
the
> fallback to global scope.
>=20
>=20
>> use function *; // don't know what this does, but apparently it's =
good for
>>> performance =C2=AF\_(=E3=83=84)_/=C2=AF
>>=20
>> Or: =E2=80=9Cdon't know what this does, but apparently it silences =
deprecation
>> notices...=E2=80=9D
>>=20
>=20
>=20
> 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.
>=20
> 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.
>=20
>=20
>=20
> 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:
>>=20
>> use function from global namespace;
>>=20
>=20
>=20
> 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:
>=20
> declare(lookup_functions_in_current_namespace=3Dfalse);
>=20
> 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.
>=20
> Regards,
> --=20
> Rowan Tommins
> [IMSoP]


I wasn=E2=80=99t clear enough in my previous post: I was assuming that =
the ultimate goal was to remove (after deprecation) the fallback to =
global namespace. In that regard, the `use function *` declaration (or =
whatever variation of that) is both a way to programmer to say the =
preferred semantics regarding not-fully-qualified function names, and a =
tool to let most legacy scripts survive without too much effort.

But probably I made a too strong assumption about the intended goal of =
the proposed feature?

=E2=80=94Claude