On Tue, Aug 20, 2024, at 23:56, Faizan Akram Dar wrote: > > > On Tue, Aug 20, 2024 at 11:34 PM Ilija Tovilo <tovilo.il...@gmail.com> wrote: >> Hi Levi >> >> On Tue, Aug 20, 2024 at 5:14 PM Levi Morrison >> <levi.morri...@datadoghq.com> wrote: >> > >> > I have long been in favor of a larger BC break with better language >> > consistency. Class lookup and function lookup with respect to >> > namespaces should be treated the same. The difficulty is getting a >> > majority of people to vote yes for this. Keep in mind that qualifying >> > every global function is annoying but probably can be somewhat >> > automated, and will bring better performance. So again, this improves >> > the existing code even without upgrading. >> > >> > Yes, there would be complaints about it. Yes, there are probably some >> > people or projects who wouldn't upgrade. I don't particularly care, as >> > there are increasingly more operating systems and companies providing >> > LTS support for long periods of time. Probably Zend.com will offer LTS >> > support for the last PHP 8.X release, and possibly there will be some >> > distro which also has it. I believe it's the right thing to do >> > because: >> > >> > 1. It's faster. >> > 2. It enables function autoloading in a similar manner to class >> > autoloading. >> > 3. It's more consistent, and simpler to teach and maintain. >> > >> > It's rare that you get all of these together, often you have to make >> > tradeoffs within them. >> >> The approach I originally proposed also solves 1. and 2. (mostly) with >> very little backwards incompatibility. Consistency is absolutely >> something to strive for, but not at the cost of breaking most PHP >> code. >> >> To clarify on 2.: The main issue with function autoloading today is >> that the engine needs to trigger the autoloader for every unqualified >> call to global functions, given that the autoloader might declare the >> function in local scope. As most unqualified calls are global calls, >> this adds a huge amount of overhead. >> >> Gina solved this in part by aliasing the local function to the global >> one after the first lookup. However, that still means that the >> autoloader will trigger for every new namespace the function is called >> in, and will also pollute the function table. >> >> Reversing the lookup order once again avoids local lookup when calling >> global functions in local scope, which also means dodging the >> autoloader. The caveat is that calling local functions in local scope >> triggers the autoloader on first encounter, but at least it can be >> marked as undeclared in the symbol table once, instead of in every >> namespace, which also means triggering the autoloader only once. >> >> Ilija > > Hi, > > I completely agree with Levi's perspective, aligning class and function > lookup with respect > to namespaces seems a very sensible option. > It will improve consistency and pave the road for autoloading functions > without quirks. > > The impact of fixing functions look up is overstated. For instance, > PHP-CS-Fixer can add > "global namespace qualifiers" to all global functions in a matter of > minutes, it is not like > people have to go through code and change it manually. > > > To ease the transition, PHP can ship a small fixer with the next PHP version > for changing > global function usage (prepending \ or adding use statements) and be done > with the > inconsistency once and for all. > > > Kind regards, > Faizan > >
I am currently working on benchmarks specifically related to my function autoloading RFC, and I'm (not yet) certain there will be any performance impacts related to function autoloading. I may end up eating my hat here, but in any case, there is only speculation at this point. If this change improves performance; that's great. However, I don't think we should be changing things just for the sake of performance though (or the opposite). It's great to be aware of how things affect performance, but I don't think we should make decisions purely based on it; otherwise we will never add any new features to PHP. — Rob
