On Tue, Aug 20, 2024, at 10:41, Nick Lockheart wrote: > > > We would upgrade that to a warning in PHP 9.2, and it would end up > > being an error on PHP 10 and have a BC break. > > > > I don't think adding a \ to each function call is ugly, that's what > > we have for classes, and it works fine; or an use statement. > > > > So, why do we think that after people get used to it, they would > > still consider it ugly? Never heard the "ugliness" mentioned for > > classes. > > > Respectfully, I think `\` is ugly for both functions and classes. > > > > Now, I know this would be a big BC break, but it brings consistency > > to the language and forces everyone to improve their code > > performance. > > There should be a directive for this, like: > > namespace foo using global functions; > > ...which automatically acts as if all functions have a \ in front of > them, unless they are fully qualified. >
Respectfully, I feel like this gets into the heart of a problem with RFCs, where if someone wants to implement something, they have to solve everyone’s problems. In this case, there is a problem with performance issues due to multiple lookups (though, I’m not convinced fully), so if someone wants to implement function autoloading, they also have to solve this problem (Gina and I have both independently solved it in various ways). Personally, I’m of the opinion that if you want performance, you know what to do: fully qualify your names. If you don’t care (which is what I gather from the first email in this thread where maintainers were not willing to change their code), then “deal with it.” The vast majority of performance issues won’t be caused by function lookups, but by databases and poorly written code. Maybe I am wrong, but I rather like what we currently have, whatever benchmarks have to say on the matter. — Rob
