Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108230
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>, Nikita Popov
	<nikita.ppv@gmail.com>
CC: Mark Randall <marandall@php.net>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
Thread-Index:
 AQHVwNgGtev425C1jEaW2/fYCDQJoKfqjUCogAA6vwCAABZSCIAF7qHQgAA+1YCAABKbIoAI/p4AgAAC2gCAABgFtQ==
Date: Fri, 24 Jan 2020 17:58:50 +0000
Message-ID:
 <DM5PR07MB30671C0F3103E927A1532B6CF90E0@DM5PR07MB3067.namprd07.prod.outlook.com>
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>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [AWcfyrkZlXxJWaZ7E37I08EL7vPHQ1CR]
x-ms-publictraffictype: Email
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: e7a32a12-736a-4d68-c4b7-08d7a0f71139
x-ms-traffictypediagnostic: CO1NAM11HT090:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 9+JXML1hv9Dx0FSsfH5UTPH2oN3Fpyjsk3ZRUJg8I2ogy8dc5PHEwWjx6bx72UDWbFZ4ARqW1cR/HDgC5ORQcIqxCZmZkdkRmHMEd5MXde8DZjZf7soh092ZSTdc/2sohyh8UVqdUtMH3rmzoL1rRzMOTFwJZ2orDT3JM7PFSDi0U2ZJf1hRh0IV90EFEd87xJk9vBrOTHbUHIuOuKFTQvlydh33KW9MP7tiAsb0CM4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: e7a32a12-736a-4d68-c4b7-08d7a0f71139
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 17:58:50.1979
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT090
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: tysonandre775@hotmail.com (tyson andre)

> > One option that I haven't seem much discussion on is the opposite: Alwa=
ys=0A=
> only look in the global namespace. Any unimported unqualified usages will=
=0A=
> > be treated as fully qualified names. This would match the proposed=0A=
> > semantics for functions/consts and change the resolution rules for clas=
ses.=0A=
> > =0A=
> > I think this would have relatively little impact on how code is written=
, as=0A=
> > classes already tend to make extensive use of cross-namespace reference=
s=0A=
> > and the import is usually IDE managed.=0A=
> =0A=
> Quick reaction: that'd make sense to me!=0A=
> =0A=
> Adding a "use CurrentNamespace\Foo" or using "namespace\Foo" looks easy e=
nough to adopt.=0A=
> Does this mean you're suggesting to use =0A=
> declare(symbol_lookup=3D'global')? Or shorter: declare(lookup=3D'global')=
, or=0A=
> maybe even declare(global_lookup=3D1) as I'm not sure we need 3 options h=
ere?=0A=
=0A=
The RFC has been updated after feedback, but I forgot to update the wiki an=
d PR title.=0A=
=0A=
I sent out an email last week mentioning that https://wiki.php.net/rfc/use_=
global_elements=0A=
is now a single `declare()` setting `declare(function_and_const_lookup=3Dgl=
obal)`=0A=
=0A=
> Always only look in the global namespace.=0A=
=0A=
Other RFCs have proposed that approach.=0A=
I mentioned the objections others had to that RFC in=0A=
https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_=
root_namespace_instead=0A=
=0A=
"Deprecating the behavior of existing code would break (possibly unmaintain=
ed) third-party libraries=0A=
and require a lot of code changes, discouraging updates to the latest versi=
on of PHP."=0A=
=0A=
> I like the idea of using a meaningful value here, but think that this=0A=
> should be using a string, i.e. declare(function_and_const_lookup=3D'globa=
l')=0A=
> rather than declare(function_and_const_lookup=3Dglobal). Currently declar=
e()=0A=
> syntax uses a normal constant expression on the right hand side of the =
=3D,=0A=
> and I don't see a strong reason why we should deviate from that for this=
=0A=
> feature. An existing declare using a string is declare(encoding=3D'UTF-8'=
).=0A=
=0A=
Whether it's quoted is a low priority to me - I went with the unquoted impl=
ementation=0A=
because it might be something repeated in every file of a project,=0A=
and it'd be slightly more convenient to avoid quotes and use keywords if th=
ere were=0A=
many more settings with different values (=3Don, =3Doff, =3Dwarning, etc) i=
n the future.=0A=
A difference is that it makes sense to quote encodings such as UTF-8 becaus=
e of the '-',=0A=
but not as much to quote keywords without special characters.=0A=
=0A=
> It looks like the implementation has been updated to the style proposed=
=0A=
> here, while the RFC still uses disable_ambiguous_element_lookup.=0A=
=0A=
Fixed, forgot to update the wiki after updating the implementation=