Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108132
MIME-Version: 1.0
References: <DM5PR07MB3067B7578E3F04C5A20A221AF9210@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CY4PR07MB30633FFAAF6E9CC45B3ECB43F9340@CY4PR07MB3063.namprd07.prod.outlook.com>
In-Reply-To: <CY4PR07MB30633FFAAF6E9CC45B3ECB43F9340@CY4PR07MB3063.namprd07.prod.outlook.com>
Date: Tue, 14 Jan 2020 22:51:58 +0100
Message-ID: <CAF+90c9svofd0rJV9ooDUb+rgsgE4+cbaahUnLzYqrksY+d=WA@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d674cb059c209a72"
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d674cb059c209a72
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 14, 2020 at 7:27 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> > This RFC proposes to support an opt-in "use global functions/consts;"
> statement
> > to disable PHP's check for the function/const in the current namespace
> before falling back to the global namespace.
> >
> > https://wiki.php.net/rfc/use_global_elements
> >
> >
> > Earlier discussion can be found in the 'Opt-in "use function *;" for
> skipping check for
> > function/const in alternate namespace' email thread, which can be seen at
> https://externals.io/message/107877
> >Let me know if you have any comments on the RFC
>
> I plan to update the wiki and start the voting phase tomorrow with the
> voting structure mentioned in https://wiki.php.net/rfc/use_global_elements
> Alternatives/Arguments
> <https://wiki.php.net/rfc/use_global_elementsAlternatives/Arguments>
> mentioned in this thread have had summaries added in the discussion section.
>

Hi Tyson,

I don't think it's a good idea to resolve the question of "use global
functions" vs "declare" as a subsidiary vote. At least in my mind, those
two options are significantly different, and this choice would affect both
my overall opinion of the proposal and also the answer I would give on some
of the other voted question.

The RFC already outlines a number of reasons why it is preferable to
implement this as a declare directive, so please excuse my reiterating some
points here :)

First and foremost, if we ever implement
https://wiki.php.net/rfc/namespace_scoped_declares or some similar way of
specifying declares on the package level, and I think it's pretty likely
that we're going to do this in one form or another, then we're very much
going to regret not making this a declare. Disabling the namespace
fallback, just like the use of strict types, is something you will usually
want to do for an entire library/project, not just for individual files.
Going for something like "use global functions" preemptively precludes this
for no good reason.

Second, I think phrasing the semantics in terms of a change to name
resolution behavior (which the declare does) is clearer than phrasing it as
"import all functions/consts in the global namespace". That's not really
what this this feature is doing on a technical level, and this phrasing is
what results in questions regarding the behavior for various conditions
regarding symbol overlaps etc. For example, with the declare, I don't think
that it should be an error to make a function declaration inside a
namespace -- that's still entirely well defined, and I think a legitimate
use-case (a project that is disabling namespace fallback everywhere, will
likely want to do that for files declaring functions as well, as a matter
of consistency.)

Third, I'm not sure it makes sense to separate this functionality for
functions and for constants. I can't really imagine a situation where you
would want to, say, use namespaced constants but global functions. I can
see why you went with this split when using the "use" syntax (as we already
have "use function" and "use const" both), but with a declare approach, I
would suggest to combine both. Functions and constants live in different
symbol spaces, but their name resolution behavior is the same.

Finally, if you do want to go with the "use" syntax, "functions" and
"consts" should not be made reserved keywords. There is no technical need
for these to be true keywords, so we can avoid an unnecessary BC break here.

Regards,
Nikita

--000000000000d674cb059c209a72--