Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120192 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 2813 invoked from network); 5 May 2023 15:13:42 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 May 2023 15:13:42 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 09BC2180549 for ; Fri, 5 May 2023 08:13:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_05,SPF_HELO_PASS, SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS30827 82.113.144.0/20 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Fri, 5 May 2023 08:13:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id CB76910C401; Fri, 5 May 2023 16:13:40 +0100 (BST) Date: Fri, 5 May 2023 16:13:40 +0100 (BST) To: "G. P. B." cc: PHP internals In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-153367609-1683299620=:41807" Subject: Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading From: derick@php.net (Derick Rethans) --8323329-153367609-1683299620=:41807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 10 Apr 2023, G. P. B. wrote: > Hello Internals, >=20 > Dan and I would like to propose a new core autoloading mechanism that fix= es > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading >=20 > The existing SPL autoloading functions would become aliases to the new Co= re > ones and will continue to work without any migrations needing to be > performed. >=20 > Hope to hear your opinions about this! I find the chosen names=20 (_register_class, _unregiester_class, _call_class,=20 _list_class, _register_function, _unregister_function, _call_function,=20 and _list_function) not very clear. From reading just their names, I=20 would have no idea of what they would do as they don't read like an=20 instruction. You're not registering a class or function, you're=20 registering a *handler* for resolving the class or function name being=20 passed in. | If a function named strlen exists in the namespace bar PHP would use=20 | that, otherwise PHP would 'fallback' to the strlen() function in the=20 | global namespace. ...=20 |=20 | When code tries to call a function that doesn't currently exist in the=20 | current namespace, the function autoloader mechanism will call the=20 | registered function autoloaders once with the fully namespaced=20 | function name.=20 Doesn't that mean that the autoloader would be called for (almost) every=20 built-in function? That sounds like a large performance hit. Even if=20 done only once per ... per what exactly? Source location? Fully=20 qualified unction name? Where is this information stored? Your line on pinning is a little vague on this. | The position of this RFC is that this behaviour is correct both from a=20 | performance point-of-view I would like to see that backed that up with hard data. | though arguably from other positions it might be less correct.=20 Which positions would that be? | The current RFC as proposed has a large BC break for the code: =E2=80=A6 = =20 | Which needs to be thought about.=20 Can you clarify what the output would be? I'm expecting: bool(false) int(1) bool(true) bool(true) int(42) Which is already confusing, IMO? Or does the first function_exists also=20 call the autoloader? Have you seen this pattern used anywhere? If it is, then this can't / shouldn't be broken in PHP 8.3, but rather=20 earlist in 9.0. | Accuracy of the naming I think that the phrasing in there indicates that there is already a=20 scope for improving on the (IMO) less than stellar proposed naming of=20 the functions that register autoload handlers. And perhaps using *type*=20 in the name is the best way forwards? cheers, Derick --8323329-153367609-1683299620=:41807--