Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125048 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 E54971A00BD for ; Mon, 19 Aug 2024 16:23:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724084741; bh=VfIAqyagjZsozoGcdgFxA5GiDT2hh3wF0AXKCxNsYnU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=L6A5XmBLYVoP/eGCMCuu0sXOt1a6lY1I2yaMO6/8ar5/0qbadWjHwsTrJizd0IPIf qzWCAbUafnCX3YV95wgLd91MkS0FzKfab9yddDVgsjbUE/eOy5Dlt4ysn3bVMq6sC1 cahpblv6OokMANToY6KsdGW4wn8tKNaimbSA+N8tNz/UJrtZfJVB9sA7eGhUKULxWr CWG93ivl5+UlLcas3k2wUt7mj9n0E7y2HG9HSwnXha4/+JKRTxbV0y6ZP7MaYIVZOi AtX/z0p44j6lNOJ4uYpJvzQu0BpmoOIB2dbRFrJNkNRix5soElVKgs/LjoZfJcKqnk 0tEnas+IYSecA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 246EA180072 for ; Mon, 19 Aug 2024 16:25:40 +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 fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com [103.168.172.151]) (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 ; Mon, 19 Aug 2024 16:25:39 +0000 (UTC) Received: from phl-compute-03.internal (phl-compute-03.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id 015B0138FD21; Mon, 19 Aug 2024 12:23:50 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-03.internal (MEProxy); Mon, 19 Aug 2024 12:23:50 -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=1724084629; x= 1724171029; bh=VfIAqyagjZsozoGcdgFxA5GiDT2hh3wF0AXKCxNsYnU=; b=F 6h4fsmK+3Ifn/BgA8ttIwfKF7/bKlIfhQV5ui19KMTed3J2a8TTLi9qA+FD3c6Tf IK5rC3NUG0k5WpKiz1D3oHqlcTWhSTQAf4tgMDCgllGJq3Jt9/Yycvi638KGbqBb JpBKpJgRoS1b3SA0fmU+GqatjEAtP9tqgDBjKbfq88MYH5OMSlLhcSKmga5yiQdj rs8Y8tKjQPU80BdZpHm7sWizyV6dS4UBVqg1bGIG72g7hGQiR6YU6PKy4DvYFKq9 /5c/NR46Edy7WrpSxYcEWsrucSU/9BT1hgCOjqGDJEnXxVxFpaPMTH9CVrcpWxMu vv638WH90ETv9VXgNiY+g== 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=1724084629; x=1724171029; bh=VfIAqyagjZsozoGcdgFxA5GiDT2h h3wF0AXKCxNsYnU=; b=FCNTqs4RhYSK1Ir4YfUzVPdpG2JIUPTaflz91nx6jBEd 2Dtv0T/+YxaQcBKOpMzZqXyDd+gGffe2Jfifz1S5HkUvV2t5AdJAcJvYnBaUwW2e 7N6iZCBpOiXT1tdfQx5p54k/XEH6oDXu9rAtnlq12LhRcwtw2z8Othp7Z5wr6Zd4 BGmFY8VCp8/rd+ImJEaIwXY5AoHhXfMDOgglavEejfEdjJ8dl135HWPouSJzLQ4m KNdTKzXntx6/4F9qr7aoxwz0UNvtuCUtEkfadY/0YmnwDJ2rV1xbdDbJDSR1Y0Go 99azNEHVbCpRW0bKaa3tZIdpYUQ18+u3tY55wLIxHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddugedguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofggff fhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhs fdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeetfe ffgedvudelgeekvdeuvdfhieffgffgvddujeeikedtledtgfekveefgefgfeenucffohhm rghinhepphhhphdrnhgvthdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggv shdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepih hnthgvrhhnrghlshesghhpsgdrmhhovgdprhgtphhtthhopehinhhtvghrnhgrlhhssehl ihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 845C515A005E; Mon, 19 Aug 2024 12:23:49 -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: Mon, 19 Aug 2024 18:23:27 +0200 To: "Gina P. Banyard" Cc: internals@lists.php.net Message-ID: <26338153-6d16-456a-81bf-8231bdaf1b79@app.fastmail.com> In-Reply-To: References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com> Subject: Re: [PHP-DEV] function autoloading v4 RFC Content-Type: multipart/alternative; boundary=51c45ba635fc4561bf1a05eef4c5cea2 From: rob@bottled.codes ("Rob Landers") --51c45ba635fc4561bf1a05eef4c5cea2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 19, 2024, at 14:03, Gina P. Banyard wrote: > On Thursday, 15 August 2024 at 17:22, Rob Landers = wrote: >> Hello internals, >>=20 >> I've decided to attempt an RFC for function autoloading. After readin= g hundreds of ancient (and recent) emails relating to the topic along wi= th several abandoned RFCs from the past, and after much review, I've dec= ided to put forth a variation of a previous RFC, as it seemed the least = ambitious and the most likely to work: >>=20 >> https://wiki.php.net/rfc/function_autoloading4 >>=20 >> Please let me know what you think. An implementation should be along = before opening it for a vote (now that I realize how important that is). >=20 > I had a quick glance at the RFC, and I really don't think this is a go= od approach or good API. > Having autoloading in SPL causes dumb issues, for example ext/session = must register it has a dependency on ext/spl just for the autoloader. [1] > This means that currently ext/session depends on ext/spl, ext/spl depe= nds on ext/standard, and ext/standard depends on ext/session, a glorious= circular dependency. >=20 > This main problem has pushed me again to rebase my PR [2] for the Core= Autoloading RFC. [3] > The wording of the RFC hasn't been updated, as this is frankly my leas= t favourite part of any RFC. > The PR passes CI and has also produced benchmark results from CI. [4] >=20 > I would rather have some collaboration on a proper solution than, IMHO= , this suboptimal solution. > I still need to get opinions from other people if it makes sense to re= move the zend_autoload_class function pointer API and have the VM direct= ly call zend_autoload. > Because from what I remember 2 years ago, some profiling tools hook in= to it to track autoloading time. > This might be improved by introducing new observer hooks. >=20 >=20 > Best regards, >=20 > Gina P. Banyard >>=20 >=20 > [1] https://github.com/php/php-src/pull/14544#issuecomment-2294907817 > [2] https://github.com/php/php-src/pull/8294 > [3] https://wiki.php.net/rfc/core-autoloading > [4] https://github.com/php/php-src/actions/runs/10441267948 >=20 Hey Gina, I=E2=80=99d love to collaborate on this feature. For what it=E2=80=99s w= orth though, I did a ton of research on it (mostly reading every discuss= ion I could find on the topic, and prior RFCs) and I felt that this API = was the most likely to be accepted. You even have a comment on your PR a= sking why not an API similar to this one (!) though your reasoning is so= und for why it is a bad idea, and I believe it is the superior API. There are some key differences between our two RFC=E2=80=99s that I thin= k are worth discussing (besides the obvious API differences): 1. in your RFC, it calls the autoloader with the global function it isn= =E2=80=99t found in both scopes. In mine, it calls it once not found in = the local scope and calls the autoloader once (for the local scope). Thi= s seemed to be a highly liked proposal in one of the older discussions (= 2013-ish?) that appeared to not result in a new RFC, as it would bypass = a lot of perceived performance issues in earlier RFCs. If an autoloader = so desires, the autoloader can check the global scope (by getting the =E2= =80=9Cbase name=E2=80=9D of the function), but autoloading the global sc= ope should be a niche application these days. 2. I like the =E2=80=9Cpinning=E2=80=9D aspect. I haven=E2=80=99t seen = your code yet, but I suspect it just registers the global function in th= e current namespace? If so, does this affect the __namespace__ global? P= robably not, but I am just curious. What happens if I manually require a= file with a pinned function in it? 3. Should we update function_exists like I did in mine to include an au= toload argument? 4. You mention no default autoloader for classes and functions, while I= agree that this should be the case, will the spl library still provide = the default class autoloader that can be registered? As far as performance for ambiguous functions go, I was thinking of subm= itting an RFC, where ambiguous function calls are tagged during compilat= ion and always resolve lexically, sorta like how it works now: echo strlen($x); // resolves to global, always require_once "my-strlen"; echo strlen($x); // resolves to my strlen, always This works by basically rewriting the function name once resolved and ma= y make the code more predictable. If I can pull it off, it can be relega= ted to a technical change that doesn=E2=80=99t need an RFC. Still workin= g on it.=20 In other words, maybe pinning could be solved more generally in a future= RFC, decrease your RFC=E2=80=99s scope and chance for sharp edge cases. In any case, if you are up for a high bandwidth conversation to collabor= ate, we can join a call, collaborate in the open, or whatever you feel m= ost comfortable with. I=E2=80=99m very excited to see this feature. =E2=80=94 Rob --51c45ba635fc4561bf1a05eef4c5cea2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19,= 2024, at 14:03, Gina P. Banyard wrote:
On Thurs= day, 15 August 2024 at 17:22, Rob Landers <rob@bottled.codes> wrot= e:
Hello internals,

I've decided to attempt a= n RFC for function autoloading. After reading hundreds of ancient (and r= ecent) emails relating to the topic along with several abandoned RFCs fr= om the past, and after much review, I've decided to put forth a variatio= n of a previous RFC, as it seemed the least ambitious and the most likel= y to work:


Please let me know what you think. An implementation s= hould be along before opening it for a vote (now that I realize how impo= rtant that is).

I had a = quick glance at the RFC, and I really don't think this is a good approac= h or good API.
Havi= ng autoloading in SPL causes dumb issues, for example ext/session must r= egister it has a dependency on ext/spl just for the autoloader. [1]
<= /div>
This means that current= ly ext/session depends on ext/spl, ext/spl depends on ext/standard, and = ext/standard depends on ext/session, a glorious circular dependency.
=

This main problem has pushed me again to = rebase my PR [2] for the Core Autoloading RFC. [3]
The wording of the RFC hasn't been update= d, as this is frankly my least favourite part of any RFC.
The PR passes CI and has also pro= duced benchmark results from CI. [4]

= I would rather have some collaboration on a proper solution than, IMHO, = this suboptimal solution.
I still need to get opinions from other people if it makes sense = to remove the zend_autoload_class<= /span> function pointer API and have the VM directly call zend_au= toload.
Because fro= m what I remember 2 years ago, some profiling tools hook into it to trac= k autoloading time.
This might be improved by introducing new observer hooks.


Best re= gards,

Gina P. Banyard=


[1] https:= //github.com/php/php-src/pull/14544#issuecomment-2294907817
[2] https://github.c= om/php/php-src/pull/8294
[3] https://wiki.php.net/rfc/core-autoloadi= ng
[4] https://github.com/php/php-src/actions/runs/10441267948



  1. in your RFC, it calls the autoloader with the global= function it isn=E2=80=99t found in both scopes. In mine, it calls it on= ce not found in the local scope and calls the autoloader once (for the l= ocal scope). This seemed to be a highly liked proposal in one of the old= er discussions (2013-ish?) that appeared to not result in a new RFC, as = it would bypass a lot of perceived performance issues in earlier RFCs. I= f an autoloader so desires, the autoloader can check the global scope (b= y getting the =E2=80=9Cbase name=E2=80=9D of the function), but autoload= ing the global scope should be a niche application these days.
    2. <= li>I like the =E2=80=9Cpinning=E2=80=9D aspect. I haven=E2=80=99t seen y= our code yet, but I suspect it just registers the global function in the= current namespace? If so, does this affect the __namespace__ global? Pr= obably not, but I am just curious. What happens if I manually require a = file with a pinned function in it?
  2. Should we update function= _exists like I did in mine to include an autoload argument?
  3. = You mention no default autoloader for classes and functions, while I agr= ee that this should be the case, will the spl library still provide the = default class autoloader that can be registered?



--51c45ba635fc4561bf1a05eef4c5cea2--