Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108309
To: Theodore Brown <theodorejb@outlook.com>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [VOTE] declare(function_and_const_lookup='global')
Thread-Index: AQHV1kkfok/EDBhgHUCIMQks+1sXM6gBAjmJgAAotzg=
Date: Wed, 29 Jan 2020 06:18:57 +0000
Message-ID:
 <DM5PR07MB30677E3C04BD2C5086F198A9F9050@DM5PR07MB3067.namprd07.prod.outlook.com>
References:
 <DM5PR07MB30670BE1BAF74AAC2B4486DBF9050@DM5PR07MB3067.namprd07.prod.outlook.com>,<BYAPR05MB653585B875D8625B21CF4142DE050@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To:
 <BYAPR05MB653585B875D8625B21CF4142DE050@BYAPR05MB6535.namprd05.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [e0fwPN1Vvo40FOTi18Vt5YT3ms45Nko0]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: b7afcbb1-2175-4306-5143-08d7a4831fee
x-ms-exchange-slblob-mailprops:
 RYAnQZ7D9SSJLgqeckR+Lg+O34Z2TZc/cWpIJYsLfguMJiwe8aY/7orDqFSOwwdNdzFszcQj1eiKSwNtv5FUqbw12LW3e6lmF6gVnj7A5rmz5JpnMWy1ejfscJHXhYnd+H0Mndd5czoHNj/k+gNqqfSHrkyEC/6CBpfJF9aC2532xnB4h2Iv8APd2RdtDKvA716291J9Q5smf3BirWStMkk7qrJHNd8sf3Q6yffm2/oCDj3/wXe0ohGUT97+oLSIpM10od8yN5j25ap2k6L0V8q1l/ojvH4hCgkmhOZ4hSnD+GX5j2XO1cmm14G/Tw3vOeuVBhnAuQiPCIGlPrgVriO1PuxJy3dSR59al6RD1olXE0zW0A2N6XEjdSgReMQpxQSHWkazHXH6m7idawHrQXybPcvhp6NCOnc7d9aEKhGFuMybZjJhoaCBtN5L68gwkqIWvK4j8FI1Hf0/T4BatvC72eStbn1Cie6LPi3BgmvPEMZtKvNmIiDEeR/hVi9+M2taUKda0QfbnpwVQp7xTfJVs5n/OdDW2eHfD6zkoOBx9BbSn8wL+vBIvcZZ3fA4U7EOUd8hpVD8CnbsF3O7ECJLyx6vMmCA3BOcAVdTn7STH+BEj7sAvsS0WZa15T3KfnH7NIhqz8tPavG3OA+GEqrA/fCdFh50uzvaLDMtYZI4gfs9GAUSQqCykStqTcW8hBEmY9mJ3qzAU3bZmeZSujEJLconsbbLT01CSWl9HUC+p97GLbBccHVlrNxljLg6fmZFnGQghH+10YU2BFDbrF04VAxe+9plLCZZo//p6tCD/8pdSU5EcTc3cK2PNfw5XNZwC1ut0qLwFGWmwlTSjZelM8QVOA7jL/mPV9SC1Erpjv03IQi5tZg1TJG6kYwJp4uiHL/X1XMad97pGwt6pEiw7lacf7ta
x-ms-traffictypediagnostic: BN8NAM11HT037:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 A2hdjXVth8kvNwzKdZLwmEuo7b2y+t6zZPfKJArFMoVsrOit8EnEMIwcOzEyodGZaM4WGnM9xGDjD7LTTnaBCFbTjrXw7jl1pbwvaQw4EMIcAGFRB0Fx8bu4epYo4j2LbAnNwHcn1K4qwsrQ4bndH1ThB21xtGuEMIJisv9loYGem116FOh4ilsaMZCWYbM9nUUm475WqphypbWN0dsYRQFsndgEwdtxokVYuixJ/7s=
x-ms-exchange-antispam-messagedata:
 1qcmIeyVj4zzUe/27zYejJ7ghrZdsegZxuMbkfdIYxRqL1eMz7WIb42wrT18bmr0/MySn7EOaiOdbk5cYRyu9pzw2MaKb2j+FtefrFIBsB9O8wUNXn4UUlQVXPobbY3TfgXj2CoGNCrGXelWgTj/JQ==
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: b7afcbb1-2175-4306-5143-08d7a4831fee
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 06:18:57.8578
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM11HT037
Subject: Re: [VOTE] declare(function_and_const_lookup='global')
From: tysonandre775@hotmail.com (tyson andre)

> Thank you for working to address the issue of ambiguous function referenc=
es. However, I really don't think this is the right approach.=0A=
>=0A=
> The RFC mentions two problems it hopes to solve: a minor performance decr=
ease, and developers having to deal with ambiguity.=0A=
> However, a third problem that I think is just as important to fix is the =
lack of function autoloading which makes extensive use of namespaced functi=
ons unfeasible.=0A=
>=0A=
> Unfortunately, the new directive proposed by this RFC would make declarin=
g functions in namespaces even more difficult, as it would now be necessary=
 to explicitly `use` each function and constant in the same file it is decl=
ared in.=0A=
=0A=
I'd expect that autoloading of those declared functions would work whether =
or not the functions were *declared* in a file with or without `declare(fun=
ction_and_const_lookup=3D'global')`.=0A=
It'd be the *uses* of the functions that would be problems, if function aut=
oloading was implemented but limited to uses of names that could be resolve=
d without fallbacks.=0A=
=0A=
As I see it,=0A=
- Many forms of function autoloading would be argued against if most PHP co=
de would end up ambiguously referencing functions,=0A=
  because you either sacrifice performance or correctness to deal with the =
ambiguity. (right now, php permanently caches the resolved ambiguous functi=
on the first time it is called)=0A=
- If unambiguously referencing functions was made less difficult, then ther=
e would be more support for implementing function or constant autoloading.=
=0A=
=0A=
> The RFC argues that having to "add multiple `use function function_name` =
and `use const MY_CONST` at the top of the namespace" is prone to merge con=
flicts and inconvenient to keep up to date. However, the RFC just shifts th=
is problem from global functions to namespaced functions.=0A=
>=0A=
> Changing function/const resolution to always look in the global scope ins=
tead of current namespace is backwards from how classes and interfaces are =
resolved, and seems destined to become another language Sadness.=0A=
> Wouldn't it be more straightforward and intuitive to add a directive like=
 `declare(namespace_lookup=3D1)` which would resolve functions/consts the s=
ame way as classes (without the global fallback)?=0A=
=0A=
https://wiki.php.net/rfc/use_global_elements#look_up_elements_in_the_curren=
t_namespace_instead_of_the_global_namespace=0A=
was brought up earlier.=0A=
Right now, the majority of PHP's functions are in the global namespace. (co=
unt(), strlen(), is_string(), etc.)=0A=
I agree it'd be more straightforward, but I don't have a personal reason to=
 propose or use a change that would make core functionality such as `is_str=
ing` harder to use.=0A=
If php's core functions and constants weren't almost all in the global name=
space, then I'd have more reasons to propose `declare(namespace_lookup=3D1)=
` instead of this.=0A=
=0A=
> The RFC argues that writing global functions as `\function_name()` is mor=
e verbose.=0A=
> But is one backslash character per global function call any more verbose =
than having to add a 44-character declare statement at the top of every fil=
e?=0A=
> Developers are already used to referencing global classes and functions w=
ith backslashes or explicit `use` statements,=0A=
> and in a future where we have function autoloading and utilize more names=
paced functions,=0A=
> this approach will be less verbose than having to explicitly `use` every =
namespaced function in the same file it is declared in.=0A=
> Plus, IDEs and other tools can automatically add the backslashes or `use`=
 statements for global functions.=0A=
=0A=
To expand on why I'm suggesting this as an alternative to `\function_name()=
` in https://wiki.php.net/rfc/use_global_elements#introduction,=0A=
=0A=
- A developer context switching between code bases that require/prefer `fun=
ction_name()` and another requiring `\function_name()` would not get used t=
o it.=0A=
  If function_and_const_lookup=3D'global' was added, they would not need to=
 context switch, and would just write `function_name()` in both projects.=
=0A=
=0A=
  Having the equivalent of a `.phpeditorconfig` could avoid the need for th=
inking about it,=0A=
  but getting that supported in all common IDEs would have roadblocks=0A=
  (e.g. hypothetical plugins may require the user must configure the path t=
o php 7.4 for their .phpeditorconfig to work,=0A=
  and there's no such thing of .phpeditorconfig for php syntax to my knowle=
dge)=0A=
- I'd prefer the syntax for unambiguously using built-in functionality be c=
onvenient to use.=0A=
- New contributors to a project wouldn't expect that builds fail (etc.) bec=
ause the `is_string` wasn't quoted.=0A=
  Many wouldn't have their IDEs set up to do add the use statements or `\`.=
=0A=
- For existing projects that start switching to unambiguous names,=0A=
  `git blame` would be less useful on the line `if (!\is_string()) { ... }`=
 because the most recent commit could be one one adding the `\`.=0A=
- This provides another option for developers that did want less ambiguity =
but=0A=
  didn't want to use either `use function function_name;` or `\function_nam=
e()` for the reasons mentioned.=0A=