On Fri, Aug 23, 2024, at 19:32, Ilija Tovilo wrote: > On Fri, Aug 23, 2024 at 5:49 PM Rowan Tommins [IMSoP] > <imsop....@rwec.co.uk> wrote: > > > > Other proposals aim to shift that balance - leaving some inconsistency, but > > less compatibility break. > > > > And most users don't object to using a leading backslash, they just (quite > > reasonably) have no idea what impact it has on the ability of the engine to > > optimise their code. > > For some context: Before proposing this change, I asked Symfony if > they were interested in disambiguating calls to improve performance, > given I did some work to make fully qualified calls faster. But they > were not, stating that the change would be too verbose for their > liking.
I think if someone values code beauty more than speed, they can do that. Although, I find that rather hilarious when their code base is littered with goto, “for speed.” What it really sounds like is that they realized you would just change the language and they wouldn’t have to review those changes… /s > > Making unqualified calls to mean local would force Symfony into making > the change, which is not the approach I'm interested in taking. Making > them global would likely reduce breakage by much, but not nearly as > much as keeping the fallback. I don’t think changing the language for a specific framework(s) is a good idea. > > From reading the responses, it seems we have three primary camps: > > 1. People who don't think BC is a problem, and would like to drop > either the global or local lookup entirely, requiring disambiguation. > 2. People who do think BC is a problem, and would like some opt-in > mechanism to explicitly pick global or local scope. > 3. People who aren't convinced that the performance improvements are > worth it to begin with, or that the developers themselves are > responsible for disambiguation. > > IMO, 1. is too drastic. As people have mentioned, there are tools to > automate disambiguation. But unless we gain some other benefit from > dropping the lookup entirely, why do it? Consistency with class > lookups is a factor, but is it enough to break a large portion of > codebases? The summed up time of every maintainer installing and > running a tool that modifies a large portion of the codebase, and then > dealing with conflicts in existing branches is not miniscule. Fixing > local calls will also require context from other files to correctly > disambiguate. I'm not aware if any tools actually consider context, or > just take the naive approach of making known, internal calls global, > and leaving the rest. Aren’t we doing that anyway with your proposal? Sure, maybe that doesn’t require (much) changes, right now. But there is an RFC being discussed right now which introduces a new function called “parse_html” This seems like a super generic name that did not take global-first into account. I know for a fact I have seen code with that exact function name several times in my career. > > 2. misses the point of the immediate performance gains without > modifications to the codebase. Even if the disambiguation itself is a > one-liner, it still needs to be added to every codebase and every > file, and still requires fixing actual local calls that may be made > within the same file. > > I obviously also disagree with 3. as I wouldn't have sent this > proposal otherwise. :) Performance improvements are hard to come by > nowadays. It was measured on real codebases (Symfony and Laravel). > > Ilija > Applications are more likely to get better performance gains in symfony by uninstalling doctrine and writing optimized queries, to be completely honest. — Rob
