On Tue, Aug 20, 2024, at 23:56, Faizan Akram Dar wrote:
>
>
> On Tue, Aug 20, 2024 at 11:34 PM Ilija Tovilo <[email protected]> wrote:
>> Hi Levi
>>
>> On Tue, Aug 20, 2024 at 5:14 PM Levi Morrison
>> <[email protected]> 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