Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107957
To: 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/fYCDQJoKfWyWcAgAABfxQ=
Date: Thu, 2 Jan 2020 05:37:21 +0000
Message-ID:
 <DM5PR07MB30671E9EDE3DEF62F52512EDF9200@DM5PR07MB3067.namprd07.prod.outlook.com>
References:
 <DM5PR07MB3067B7578E3F04C5A20A221AF9210@DM5PR07MB3067.namprd07.prod.outlook.com>,<f659647c-1e79-4c4e-b57b-a1d93e76528b@BN8NAM11FT047.eop-nam11.prod.protection.outlook.com>
In-Reply-To:
 <f659647c-1e79-4c4e-b57b-a1d93e76528b@BN8NAM11FT047.eop-nam11.prod.protection.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [xz6vzP0xHySgf44Hos03buZHeybkldSzkFC4jwKWCVWmn2/Yb7z82qX0/6a4XUKW]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: f8169f43-21f9-42e9-b956-08d78f45d713
x-ms-traffictypediagnostic: SN1NAM02HT195:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 Vr0DCqcBJRsF4dkryuYjqxEa9d5rgIrPj+pC98wE1BQALoPpo+PZG9UObqfn3EzkjFioZI+tncWduAOvTgiyoxzJw62Os8lwDmTfPrEcVh661MMLy8Wb9R75t1B6nyt//dZNOeCPLpj/noMVc9lcMsSTRzWsT89VD1/KmAU62T9s7DmM9rDUwnGQCwNIQADd
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: f8169f43-21f9-42e9-b956-08d78f45d713
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 05:37:21.9619
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT195
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: tysonandre775@hotmail.com (tyson andre)

> It's an interesting idea, but at this time I think it's the wrong =0A=
> approach to what is in the best long-term interests of the language by =
=0A=
> introducing an additional point of inconsistency.=0A=
> =0A=
> Classes search the current namespace, but functions / const would search =
=0A=
> namespace first, unless they don't, then global?=0A=
=0A=
Assuming you mean "unless they don't" is the additional inconsistency:=0A=
=0A=
I still see this as a cleaner/less verbose option than the currently availa=
ble options=0A=
for avoiding ambiguity - aliases add similar resolution behavior.=0A=
=0A=
"function_name() will search the current namespace first,=0A=
then the global namespace,=0A=
unless "use function [.... as] function_name" was found=0A=
earlier in the namespace block."=0A=
=0A=
> For the very minor one-time performance hit (thanks to the cache slot), =
=0A=
> I think the situation is best remaining as-is for the time being.=0A=
=0A=
That was unintuitive to me -- but it is one-time.=0A=
(ignoring optimizations of specialized opcodes=0A=
and inlining results as constants)=0A=
Running the following example outputs "Length is 4" twice.=0A=
=0A=
<?php=0A=
namespace NSTest;=0A=
function computeStrlen() {=0A=
    printf("Length is %s\n", strlen("test"));=0A=
}=0A=
computeStrlen();=0A=
require 'b.php';=0A=
computeStrlen();=0A=
// contents of b.php=0A=
<?php=0A=
namespace NSTest;=0A=
function strlen($x) {=0A=
    return -1;=0A=
}=0A=
=0A=
> In future, I think the optimal solution is opt-in deprecating fallback =
=0A=
> to the root namespace using a declare.=0A=
> ... Id like to see nikic/scalar_objects added to the core in 8.0=0A=
=0A=
Various global functions (strlen(), count(), class_exists(), is_string(), e=
tc.)=0A=
are more frequently used than namespaced functions in many files,=0A=
and removing the fallback *to* the global scope would break most third part=
y code,=0A=
which might be unmaintained.=0A=
This backwards compatibility break would discourage upgrading=0A=
to future major versions.=0A=
=0A=
> That doesn't cover defined constants, but IMO we should be pushing those =
=0A=
> to be moved into class constants, simply because in the absense of =0A=
> function / constant / anything-but-class level autoloading, things might =
=0A=
> as well be in a readily available location.=0A=
=0A=
Out of scope of this RFC: I had a thought today about autoloading.=0A=
I'd rather improve function / const autoloading instead of moving to classe=
s. =0A=
What if an ambiguous function_name() or const outside the global =0A=
namespace would attempt to autoload *ambiguous* functions in the global sco=
pe,=0A=
but not the current namespace?=0A=
(and autoload unambiguous functions in their respective scope)=0A=
function_exists() or defined() would not autoload,=0A=
to preserve the behavior/performance of current programs.=0A=
Anything with the callable type hint (e.g. array_map) would also need to be=
 modified.=0A=
=0A=
- Same for global constants=0A=
- That should avoid the performance hit - this autoloading would only be tr=
iggered=0A=
  when php would previously throw an Error or warning=0A=
  for undefined functions/constants.=0A=
- This would also avoid the need to load polyfill files (e.g. mbstring)=0A=
  or test framework files when their functions/constants are unused.=0A=
- The main blocker for other autoload proposals=0A=
  seemed to be performance if I understood correctly=0A=
  (e.g. attempting to autoload NS\strlen() every time strlen was called)=0A=
=0A=
Fully-qualified calls (through use, \, or being in the global scope) would=
=0A=
autoload the unambiguous name for missing functions.=0A=
=0A=
And there'd have to be a hash map or other check=0A=
to avoid recursion on the same constant/function.=