Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125077 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 940701A00BD for ; Tue, 20 Aug 2024 22:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724192587; bh=rIHdjOxMpDt63ZRJWbOs2jdoxb33wTJwngz9LcT+3I4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=D6U+Oe9+bPXCfvqEA7VibIkzuzLOg5sAWLf0Kp3t7JzbjuISGrSvvDvROMMZ/EX+3 g9z+KBrma2/w0fWxCMXw/0Y//aigeMm0S4K7//RzKFI1OVwH++eEEmxcQOTL0NrpFx swl4/jZbmpREdv7uwxfjRdkDXQYXuQQ2rTEHt1zWJVZKfA2IBkHw8B0swwHq4nPzfE MEiWYrsG3AE5dVMjdzZ9cr18ucO04iYhZT4mByTCcwIMAzPBe9C1XFH05Lwfp4kz7S 5JGqtJPDA2Qwxse04UP7z1kQbkTgy6GafIi5hvIxPqnd7YA7ecVefp2Mpybzth+Tsc +pVU7oA5qRWjw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 284FA180034 for ; Tue, 20 Aug 2024 22:23:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout2-smtp.messagingengine.com (fout2-smtp.messagingengine.com [103.168.172.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 20 Aug 2024 22:23:04 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.nyi.internal [10.202.2.42]) by mailfout.nyi.internal (Postfix) with ESMTP id 967FE138FD62; Tue, 20 Aug 2024 18:21:14 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-02.internal (MEProxy); Tue, 20 Aug 2024 18:21:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1724192474; x= 1724278874; bh=onZhfEouJSlyyozyKqlSKeOOXRSuB/QSycSliXKAVqM=; b=u 7Eva77ofAWbCuEQjTc6VHPg7TBM9F+liYqVTAX11UXFfxROzs0qtIU0GeyNll4oP wgyrg4GnmhxnhDqWL8+h34PQc6rKPou6z+c7C6WtgD0T1S8W0SogPPglTp6vJQ8n Ee1r4huw8tyP/J5q0ZtKlfUmq3TqKIwO/PIC7pETrHP2Us1LrM0xBlviyunAd6+/ z91ZPHgwN9MUir9pesz5hioGQiyGspZLKKfDXcpiTMcGjnWwBAPl+ODDBujZyEW9 QDixEHOQ3jRItL+zNPAK2G4N8ynrC/KthSndbK8nVW81Ka29k920aXRlHW/i6rbm 3HmwIsG+pT8XMO9Q4+0gg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1724192474; x=1724278874; bh=onZhfEouJSlyyozyKqlSKeOOXRSu B/QSycSliXKAVqM=; b=CFMFHrCZ4cnTGZywavznMg8GhWF5w08qjkrdba3XQttN hDNFvIRkY+CWiJ/lQHspUXnVngDm3ve4SnTbLVoiaw58RzcaQSSP680AW17NfKt1 9S+xvGlXgbxSun8YBqjiPtsVsnKxzYf+fOeRudLqBxChR3BbE7UJbo9XDcUFhXnq vKUZGwonIWI/3TrEB1QktERfXrLjKwcuXID+irPMkIJhmBb1kTpmfw0ybRXi+Lq/ kLh7+0KfOsBG2R8bBRJrz7OMNv1WqevvE5ePWwZDcYgBIDv41T9fdM9IBH0avX2G aJvNA5vVH2HmXJa/Vj6YwJ0hS6Jwt0ZbKHHrfjJSyQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddujedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeen ucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtoh guvghsqeenucggtffrrghtthgvrhhnpeeiueethedvvdefjefhgfeiheelheehtdfhfeek jefflefgvedvkeduteejjedttdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphht thhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehhvghllhhosehfrghiii grnhgrkhhrrghmrdhmvgdprhgtphhtthhopehtohhvihhlohdrihhlihhjrgesghhmrghi lhdrtghomhdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvg ht X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1DFD015A005F; Tue, 20 Aug 2024 18:21:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Wed, 21 Aug 2024 00:20:51 +0200 To: "Faizan Akram Dar" , "Ilija Tovilo" Cc: "PHP internals" Message-ID: <7e09fd6a-6e97-431e-8d88-265a4ed9f1a8@app.fastmail.com> In-Reply-To: References: Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local) Content-Type: multipart/alternative; boundary=a90fd63139a2421594a9a6ffd6ec19bc From: rob@bottled.codes ("Rob Landers") --a90fd63139a2421594a9a6ffd6ec19bc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 20, 2024, at 23:56, Faizan Akram Dar wrote: >=20 >=20 > On Tue, Aug 20, 2024 at 11:34=E2=80=AFPM Ilija Tovilo wrote: >> Hi Levi >>=20 >> On Tue, Aug 20, 2024 at 5:14=E2=80=AFPM Levi Morrison >> 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 qualifyi= ng >> > every global function is annoying but probably can be somewhat >> > automated, and will bring better performance. So again, this improv= es >> > the existing code even without upgrading. >> > >> > Yes, there would be complaints about it. Yes, there are probably so= me >> > people or projects who wouldn't upgrade. I don't particularly care,= as >> > there are increasingly more operating systems and companies providi= ng >> > 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 so= me >> > 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 au= toloading. >> > 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Ilija >=20 > Hi, >=20 > I completely agree with Levi's perspective, aligning class and functio= n lookup with respect=20 > to namespaces seems a very sensible option. > It will improve consistency and pave the road for autoloading function= s without quirks. >=20 > The impact of fixing functions look up is overstated. For instance, PH= P-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. >=20 >=20 > To ease the transition, PHP can ship a small fixer with the next PHP v= ersion for changing > global function usage (prepending \ or adding use statements) and be = done with the=20 > inconsistency once and for all. >=20 >=20 > Kind regards, > Faizan >=20 > =20 I am currently working on benchmarks specifically related to my function= autoloading RFC, and I'm (not yet) certain there will be any performanc= e impacts related to function autoloading. I may end up eating my hat he= re, but in any case, there is only speculation at this point. If this change improves performance; that's great. However, I don't thin= k 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 performanc= e, but I don't think we should make decisions purely based on it; otherw= ise we will never add any new features to PHP. =E2=80=94 Rob --a90fd63139a2421594a9a6ffd6ec19bc Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 20,= 2024, at 23:56, Faizan Akram Dar wrote:


On Tue, Aug 20, 2024 at 11:34=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmail.com> wr= ote:
Hi Levi

On Tue, Aug 20= , 2024 at 5:14=E2=80=AFPM Levi Morrison
>
> I have lo= ng 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 i= s 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 upgra= de. I don't particularly care, as
> there are increasi= ngly 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 th= ere 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 autoloa= ding.
>  3. It's more consistent, and simpler to = teach and maintain.
>
> It's rare th= at 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 P= HP
code.

To clarify on 2.:= The main issue with function autoloading today is
that t= he 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 a= re global calls,
this adds a huge amount of overhead.
=

Gina solved this in part by aliasing the loc= al function to the global
one after the first lookup. How= ever, that still means that the
autoloader will trigger f= or every new namespace the function is called
in, and wil= l also pollute the function table.

Revers= ing 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 l= ocal scope
triggers the autoloader on first encounter, bu= t at least it can be
marked as undeclared in the symbol t= able once, instead of in every
namespace, which also mean= s triggering the autoloader only once.

Il= ija

Hi,
I completely agree with Levi's perspective, aligning class a= nd 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. F= or instance, PHP-CS-Fixer can add
 "global namespace = qualifiers" to all global functions in a matter of minutes, it is not li= ke
 people have to go through code and change it manu= ally.


To ease the trans= ition, 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 
inconsist= ency once and for all.


Kind = regards,
Faizan

&n= bsp;

I am cu= rrently working on benchmarks specifically related to my function autolo= ading RFC, and I'm (not yet) certain there will be any performance impac= ts 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 performa= nce though (or the opposite). It's great to be aware of how things affec= t performance, but I don't think we should make decisions purely based o= n it; otherwise we will never add any new features to PHP.

=E2=80=94 Rob
--a90fd63139a2421594a9a6ffd6ec19bc--