Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108262
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>
In-Reply-To: <CAOWwgpkmawRgSJ2J8ZMoh_0MBskOgwJu-=HGJ42=6EQt+vz0Gw@mail.gmail.com>
Date: Mon, 27 Jan 2020 10:41:29 +0100
Message-ID: <CAOWwgp=WB7sCKTovDEt6shOFZvyHWKxgCT0mdcvYHqLitCQmfw@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000198550059d1beaf3"
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000198550059d1beaf3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le ven. 24 janv. 2020 =C3=A0 17:10, Nicolas Grekas <nicolas.grekas+php@gmai=
l.com>
a =C3=A9crit :

>
> One option that I haven't seem much discussion on is the opposite: Always
>> only look in the global namespace. Any unimported unqualified usages wil=
l
>> be treated as fully qualified names. This would match the proposed
>> semantics for functions/consts and change the resolution rules for
>> classes.
>> I think this would have relatively little impact on how code is written,
>> as
>> classes already tend to make extensive use of cross-namespace references
>> and the import is usually IDE managed.
>>
>
>
> Quick reaction: that'd make sense to me!
>
> Adding a "use CurrentNamespace\Foo" or using "namespace\Foo" looks easy
> enough to adopt.
> Does this mean you're suggesting to use declare(symbol_lookup=3D'global')=
?
> Or shorter: declare(lookup=3D'global'), or maybe even
> declare(global_lookup=3D1) as I'm not sure we need 3 options here?
>

Hello Tyson,

can we please discuss this alternative? In another reply, you link to
https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_=
root_namespace_instead

But this new proposal derived from Nikita's idea is different as it doesn't
need to deprecate anything.

I'm not comfortable with having a 3-ways declare directive. Who will pick
which of the 3 and for what reason? That's going to be a mess to review. If
we're looking for a forward path, there should be only one opt-in way: a
boolean flag.

declare(global_lookup=3D1)

I think that's all we need to make all symbols resolve in the same way,
known at compile time.

You mention this should be another RFC. But process-wise, I think it would
be better to vote only once on a specific topic, vs having several
iterations that undo previous RFCs before having a stable consensus.

Thanks for considering,
Nicolas

--000000000000198550059d1beaf3--