Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94977 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26022 invoked from network); 9 Aug 2016 20:26:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Aug 2016 20:26:45 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.164 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.25.164 mx208.easyname.com Received: from [212.232.25.164] ([212.232.25.164:40100] helo=mx208.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5E/C7-03404-38C3AA75 for ; Tue, 09 Aug 2016 16:26:44 -0400 Received: from cable-81-173-132-156.netcologne.de ([81.173.132.156] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bXDbk-00034I-N7; Tue, 09 Aug 2016 20:26:41 +0000 Reply-To: internals@lists.php.net References: <33781781-2a63-78c1-68a1-9e19ad720d8d@gmail.com> <1d89ec68-de5e-2670-aed1-f12872c073c3@gmail.com> <615f02b9-0621-2e7a-bec9-af4e342529b2@gmail.com> To: Rasmus Schultz , Rowan Collins Cc: internals Message-ID: <80776a32-5eda-271f-4270-2843b453a545@fleshgrinder.com> Date: Tue, 9 Aug 2016 22:26:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kb0KOqm3tvOtaredgRTl5LQW4CC96AJ8b" Subject: Re: [PHP-DEV] Function auto-loading From: php@fleshgrinder.com (Fleshgrinder) --Kb0KOqm3tvOtaredgRTl5LQW4CC96AJ8b Content-Type: multipart/mixed; boundary="owufM3kduhNUvCLSG3mKlTXrXPmWx0Ear" From: Fleshgrinder Reply-To: internals@lists.php.net To: Rasmus Schultz , Rowan Collins Cc: internals Message-ID: <80776a32-5eda-271f-4270-2843b453a545@fleshgrinder.com> Subject: Re: [PHP-DEV] Function auto-loading References: <33781781-2a63-78c1-68a1-9e19ad720d8d@gmail.com> <1d89ec68-de5e-2670-aed1-f12872c073c3@gmail.com> <615f02b9-0621-2e7a-bec9-af4e342529b2@gmail.com> In-Reply-To: --owufM3kduhNUvCLSG3mKlTXrXPmWx0Ear Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/9/2016 7:44 PM, Rasmus Schultz wrote: > Well, no - there is still the issue of file names and paths becoming a > dependency, besides issue of having to locate the file in the first > place. >=20 > So there is still very much a purpose to this. >=20 > Importing all classes with use-statements is good practice anyhow, and > - it forces you to document at the top of your file which elements > you're referencing outside of the local namespace. Of course, that's > opinion, but it's a common opinion - you don't see too much code in > the wild with inline qualified class references, most everyone has a > leading set of use-statements in every file. >=20 > Actually, now that I think of it, for that reason, I might actually be > okay with only qualified references triggering auto-loading after all > - this would never become an issue at all, because I'd qualify > everything with use-statements anyhow. >=20 > Though I do think it would be somewhat easier to *explain* this > feature, if it was simply triggered by the use-statement, not by the > circumstance of whether the name is or isn't qualified, because it's > not always obvious from looking at the code - you'd have to look at > the use-statements first and then correlate those with function-calls > and figure it out, every time you look at a file. That mental overhead > is eliminated by just having the use-statement trigger auto-loading. >=20 > Also, come to think of it, triggering the auto-loader could still be > deferred, for performance reasons, even if the use-statement is what > triggers is - so it wouldn't aggressively trigger the auto-loader when > the use-statement is encountered, but rather the first time the a > function imported with a use-statement is called. That would be more > consistent with how class resolution works. >=20 > I think maybe this could work after all?? >=20 Having the use statement trigger the auto-loader would result in a lot of broken code because of optional dependencies (remember the examples I showed you in the annotation thread). An alternative approach could be to auto-load only namespaced things and leave non-namespaced stuff alone. This is in line with PSR-4 (rule 2.1) and easily implemented if the namespace refactoring into a struct is performed without any major additional performance hit. Note that it is trivial to support a flag in the new namespace struct for C defined namespaced functionality to circumvent the auto-loader. The introduction of the new namespace struct would require changes to every bit of PHP C code out there anyways. Of course this would also mean that the whole story would become a PHP 8 feature. This would make it even more painful for users to define anything in the global namespace; a good thing. It would however encourage people to prefix their stuff inline with a backslash, otherwise you end up with an endless use chain for every built-in feature which is not nice. That being said, it's required anyways if we are really going to introduce namespaces for everything within PHP (e.g. `use function php\random_bytes;`). Something I still think is a bad idea at least for procedural first-level functions. --=20 Richard "Fleshgrinder" Fussenegger --owufM3kduhNUvCLSG3mKlTXrXPmWx0Ear-- --Kb0KOqm3tvOtaredgRTl5LQW4CC96AJ8b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXqjx8AAoJEOKkKcqFPVVrCCUQAJNNjSkeSUGLnKAQNDBfe9Tf qkDtI+Z3JjeMrmw5PmcQL44ig4Rwi9N36jfhdnpsVh7kEOoTIuYL7dBSo7KwHaNM t9vTTQZLth3zbIHDseB62ZRsT+uKCk2mQ4sCAOoXoaup61YwHqcG2sjY25mAGLLO Qbj4Ic9wAQGlbb3KkBHpFZKpGwg5GH+UMezGn3/NRWdSQ/EoAnL7/S0VsuijzGQA q4T1OmRolNteywLIxCJaDpn2zy3wYKIsXRflwoWMEw5SX0AQQP08JdDc9r7ybhji UAD+FHU7CLJeNiytnm6MOHrBCoeiSrtfbBQDsLyVOKU7ahJZRdVHDLuNGUyCti5e YitC/ZRidWpYps59lj8lfbFZssyKXr1C/iU5yDP62NlCK3kkbEzp5le1rXHHAI/7 A5EX0930FEfjjS6Nb8FP7/6aiMeXrVW1tKexvTxnomg+lr2vP4rEYxHmOFCMRN7x 5uUUhGap87eWbdA0dOlpZIOS4t34qluZ5KE2LOBgYOE9ER6tITm0m0bBh1gAESKZ JIPGvWRjCjzJtHDzXLUerhZvx6BQfleT7lWTWVigdUBbxWkBAKPgookKFQFCSB4G +TeaAhQ2RRZ80b28+/oielmkmOmrWFM/ZU7uJ96rH8s2VgJek6C3EpYXPnA1NBWx BSYf5dYIYvDks4qdduNM =KIWa -----END PGP SIGNATURE----- --Kb0KOqm3tvOtaredgRTl5LQW4CC96AJ8b--