Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107967
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: Autoloading functions/consts without a performance impact
Thread-Index: AQHVwdV5EmiXz0tOK0a5kq9yFNlY0g==
Date: Fri, 3 Jan 2020 01:51:07 +0000
Message-ID:
 <DM5PR07MB30672DEC89A0351460769702F9230@DM5PR07MB3067.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 62393066-7f3e-410f-7b3b-08d78fef665c
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2020 01:51:07.2227
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM10HT152
Subject: Autoloading functions/consts without a performance impact
From: tysonandre775@hotmail.com (tyson andre)

After a quick search, it turns out I've mostly reinvented=0A=
https://wiki.php.net/rfc/autofunc which I hadn't remembered.=0A=
The `spl_autoload_*()` changes it mentions is what I had in mind=0A=
=0A=
There's been changes to php since then, it's been 7 years,=0A=
and this adds thoughts on some implementation details.=0A=
=0A=
It's possible to support function / const autoloading=0A=
in a way that keeps existing performance.=0A=
Some of the objections at the time no longer apply.=0A=
=0A=
- `SOME_CONSTANT` no longer falls back to the literal string in php 8.=0A=
  It throws an Error.=0A=
- APC (used by some implementations) is no longer supported.=0A=
- Many of the objections were against the available implementations=0A=
  based on `function __autoload()`, not the concept of autoloading.=0A=
=0A=
  https://www.mail-archive.com/internals@lists.php.net/msg52307.html=0A=
- There wasn't much traction from leads for the concept=0A=
  or a Proof of Concept to vote on for that RFC (I think).=0A=
=0A=
What if an ambiguous `function_name()` or const outside the global=0A=
namespace would attempt to autoload functions in the global namespace=0A=
if it would throw an Error, but not the current namespace?=0A=
=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=
but I think it already needs to do that for method arrays and 'MyClass::met=
hod'.=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=
- One 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=
  https://externals.io/message/54425#54616 and https://externals.io/message=
/54425#54655=0A=
  detail this - choosing a different order of checks avoids the performance=
 hit.=0A=
- In addition to the RFC, changing the signatures to `defined(string $name,=
 bool $autoload =3D false)`=0A=
  and `function_exists($name, bool $autoload =3D false)`=0A=
  might be useful ways to allow users to choose to autoload when checking f=
or existence.=0A=
=0A=
And there'd have to be a hash map, flag, or other check=0A=
to avoid recursion on the same constant/function.=0A=
=0A=
Background: A function call or constant usage is=0A=
ambiguous if it could look for the function in two namespaces,=0A=
as described by the rules documented in the below link.=0A=
It's unambiguous if it ends up looking in only one namespace.=0A=
=0A=
https://www.php.net/manual/en/language.namespaces.rules.php=0A=
The only type of ambiguous function call or global constant use is (7.):=0A=
=0A=
> 7. For unqualified names,=0A=
>    if no import rule applies and the name refers to a function or constan=
t=0A=
>    and the code is outside the global namespace, the name is resolved at =
runtime.=0A=
>    Assuming the code is in namespace A\B, here is how a call to function =
foo() is resolved:=0A=
>    1. It looks for a function from the current namespace: A\B\foo().=0A=
>    2. It tries to find and call the global function foo().=0A=
=0A=
My approach should be in line with the current name resolution=0A=
for unqualified names outside the global namespace.=0A=
=0A=
1. It (first) looks for a function from the current namespace: A\B\foo().=
=0A=
2. It (next) tries to find and call the global function foo().=0A=
3. (Optional) NEW ADDITION: Next, if both functions were undefined,=0A=
   the autoloader(s) attempt to autoload the function A\B\foo()=0A=
   (and call it instead of throwing if found) before proceeding to step (4.=
)=0A=
4. NEW ADDITION: If both functions were undefined,=0A=
   the autoloader(s) attempt to autoload the global function foo()=0A=
   (and call it instead of throwing if found) before throwing an Error=0A=
=0A=
And for unambiguous calls, find and autoload the only name it has.=0A=
=0A=
The fact that one of the two possible functions gets cached by the php VM=
=0A=
in CACHED_PTR=0A=
(for the lifetime of the request) the first time the function is found=0A=
in either namespace will remain unchanged with this proposal.=0A=
=0A=
(Out of scope of the "use global functions/consts" RFC,=0A=
so I'm splitting out this discussion. There is no proof of concept yet.)=0A=
=0A=
------=0A=
=0A=
Pros:=0A=
- Don't need to preload entire files and dependencies up-front whether or n=
ot they're used (e.g. with composer),=0A=
  to supply functional libraries or frameworks, or to supply polyfills for =
native modules.=0A=
- Supporting this encourages using functions/global constants from namespac=
es,=0A=
  where they were previously discouraged by lack of autoloading support,=0A=
  or needed manual require_once statements.=0A=
- Preloading support makes it easier to avoid \NS\FooDoer::foo() instead of=
 \NS\do_foo() in cases which would be unnatural (e.g. classes with just one=
 method)=