Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108269
MIME-Version: 1.0
References: <DM5PR07MB3067B7578E3F04C5A20A221AF9210@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CY4PR07MB30633FFAAF6E9CC45B3ECB43F9340@CY4PR07MB3063.namprd07.prod.outlook.com>
 <CAF+90c9svofd0rJV9ooDUb+rgsgE4+cbaahUnLzYqrksY+d=WA@mail.gmail.com>
 <DM5PR07MB3067239059A936661E1100B5F9340@DM5PR07MB3067.namprd07.prod.outlook.com>
 <DM5PR07MB3067A4F37F4D8E6738582859F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
 <b8e7ced4-9cec-4bde-a009-622c477a0e58@DB3EUR04FT030.eop-eur04.prod.protection.outlook.com>
 <DM5PR07MB306711A0E8F1CADB23C17CB5F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c-Rmmh3+iYqFmn1E+W5-S1qT4BpPhN9wgroz=9ZudeWpg@mail.gmail.com>
 <CAOWwgpkmawRgSJ2J8ZMoh_0MBskOgwJu-=HGJ42=6EQt+vz0Gw@mail.gmail.com>
 <DM5PR07MB30671C0F3103E927A1532B6CF90E0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c8uCL85dVbLgapV2gOypFNBqocqvYWDB=JHKEmrq2JCwA@mail.gmail.com>
 <DM5PR07MB30677F5577E4C2105DF7B68EF9080@DM5PR07MB3067.namprd07.prod.outlook.com>
 <A5AD5FD1-7CA1-49D9-86A0-D72EA08A84F5@gmail.com> <DM5PR07MB3067F716C9F0E6D5C2DB3D9DF9080@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c8sBcWnsZxMQNgOccHeVbDnhHmjbbRuCzO8QD9oJZA6jA@mail.gmail.com> <DM5PR07MB30675BDFD91C54AAF45E9261F90B0@DM5PR07MB3067.namprd07.prod.outlook.com>
In-Reply-To: <DM5PR07MB30675BDFD91C54AAF45E9261F90B0@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Mon, 27 Jan 2020 15:57:55 +0100
Message-ID: <CAF+90c-ATc3R6Q6=Ja1ngo-kPHqh-pTF=Bda8B-VesH6cfVqHA@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: Claude Pache <claude.pache@gmail.com>, Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	Mark Randall <marandall@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000ee8c8059d205641"
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000000ee8c8059d205641
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 27, 2020 at 3:43 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> > This would be a compile error right now though, because we don't allow
> "use"d symbols and declarations to clash.
>
> As I surprisingly discovered when implementing the RFC, they don't clash.
> The PHP interpreter has a special case where it doesn't warn or throw
> about the name being in use
> if the resolved (namespaced) name in use is the same as the element being
> declared.
> See https://3v4l.org/RtPKv - the below example works.
>
> ```
> <?php
>
> namespace NS;
> use function NS\foo;
> use const NS\BAR;
>
> function foo() { echo BAR; }
> const BAR = 3;
> foo();
> ```
>

Interesting :)


> > While I was the one who originally suggested to allow this kind of code,
> > I think it might be better to just unconditionally make it a compile
> error,
> > and require the use of declare(function_and_const_lookup='default')
> > if you want to declare namespaced constants or functions.
> >The main motivation for allowing it is interoperability with
> namespace-scoped declares,
> > but as those don't exist yet (and would still allow a per-file opt-out),
> we can delay this issue.
> >
> > I think that principally, the correct behavior here is to bring the
> symbol into scope as it is declared,
> > but as you already pointed out, this leads to unclear semantics when
> conditional function declarations are involved.
>
> The subset of code that can be written requiring "use function NS\foo;"
> and "use function NS\MY_CONST;"
> with function_and_const_lookup='default' is larger than forbidding it
> completely, while still avoiding ambiguity.
>

Right ... well, as the above code isn't a compile-error like I expected, I
guess this is fine :)


> > As a minor note, rather than using 'default' as one of the values,
> > I think it would be better to use 'fallback' to make it robust against a
> potential future change of defaults.
>
> I'd rather have that done when the future change of defaults is being
> proposed.
> Supporting 'fallback' might cause confusion and extra work if the name
> resolution defaults ever change in a different way.
> At the point where they do change, we either do or don't want a way to
> support the old 'fallback',
> but we will want to support the new 'default'.
>
> Right now, it's deliberately intended to be the same as just leaving the
> setting off for that file.


Sounds reasonable.

Nikita

--0000000000000ee8c8059d205641--