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. > > So there is still very much a purpose to this. > > 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. > > 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. > > 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. > > 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. > > I think maybe this could work after all?? >
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. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
