Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127640
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 10 Jun 2025 23:45:02 +0200
To: internals@lists.php.net
Message-ID: <4c5b7a48-1ca2-4197-a103-9d7fa94b6e36@app.fastmail.com>
In-Reply-To: <e0406bea-b6e2-47bf-b5d6-f9fea4332c5d@app.fastmail.com>
References: 
 <CANTuiHsCi30ArpBqDnyUGt5M-RUVJ7trfF5+F0Vq9EeEVuty_g@mail.gmail.com>
 <f6b47389-b4cd-4f56-9016-ad8fcff4c413@app.fastmail.com>
 <CANTuiHsK+qfVEHE1EPSLp-KmZgqFKoOj28sEERWGhUjzh5dE-Q@mail.gmail.com>
 <e0406bea-b6e2-47bf-b5d6-f9fea4332c5d@app.fastmail.com>
Subject: Re: [PHP-DEV] Feature Discussion |
Content-Type: multipart/alternative;
 boundary=b9e31c128f8b4739ab5e6e919b79dd96
From: rob@bottled.codes ("Rob Landers")

--b9e31c128f8b4739ab5e6e919b79dd96
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 10, 2025, at 22:09, Larry Garfield wrote:
> On Tue, Jun 10, 2025, at 2:45 PM, Dmitry Derepko wrote:
> > Thanks for participating, Larry.
> >
> > On Mon, Jun 9, 2025 at 10:29=E2=80=AFPM Larry Garfield <larry@garfie=
ldtech.com> wrote:
> >> 2. Please link to a PR of your actual implementation.  In context i=
t looks like your branch comparison link is to the version you said didn=
't work, so it's not that helpful.
> >
> > Correct, I don't have another one. This is big feature, I need a lot=
 of=20
> > time to implement it. I don't want to waste my time if we decide tha=
t=20
> > RFC won't pass at all.
>=20
> Understood.

I'd recommend figuring it out, even if it costs a lot of time. Some of t=
he feedback I got on nested classes -- even after working on the impleme=
ntation nearly every weekend for months -- was that the PoC code was too=
 hacky and didn't work with opcache. There are hard dates for features t=
o be merged; and if you don't hit that date ... well, fun times to be ha=
d trying to get it done by the release time, and nobody wants that crunc=
h (and the inevitable bugs that follow). There's enough to do just to ge=
t a release done. Having working code that is at least somewhat shippabl=
e is a big indicator that an RFC will pass.

>=20
> >> 3. The biggest question that has come up in the past (Ilija and I h=
ave discussed it at length) is, naturally, autoloading.  How if at all d=
o you address that?
> >
> > In the original message I mentioned `use extension` construction. Th=
is=20
> > should be enough for solution, isn't it?
>=20
> Very much not.  The `use` construct has no bearing on autoloading curr=
ently.  Autoloading happens only for classes and class-like things (inte=
rfaces, traits, enums).  If a function is not found, PHP just crashes.  =
Various solutions to this have been discussed over the years, none of wh=
ich ever made it as far as a vote.
>=20
> I toyed with the idea of having extension functions compile to a stati=
c method on a class as a way around this, but of course then you end up =
with a file-per-function, and the file name has to match not the functio=
n name, but whatever mangled class name gets generated.  Not at all intu=
itive.
>=20
> In fairness, I think with universal opcache, preloading, and the incre=
asing use of persistent processes, just skipping autoloading for functio=
ns and front-loading them via composer.json's "files" block is fine for =
the 80% case.  But it feels like I am in the minority on that position.
>=20
> >> 4. The other big question was determining when to match a given "me=
thod" call to an extension function, when the type of a variable is not =
always known at compile time.  How did you address this?
> >
> > Cannot understand the passage, could you explain more?
>=20
> <?php=20
> // index.php
>=20
> function Point.area(): int {=20
>   return $this->x & $this->y;
> }
>=20
> function doStuff($p) {
>   // At compile time, we don't know that $p is a Point. In fact, it ma=
y not be.
>   // The function will allow any value here, even a non-object, so it =
doesn't know
>   // if this should be compiled to Point__area($p) or left as is.
>   print $p->area();
> }
>=20
> The only way I could think of to handle that is to have a method call =
"trap" similar to class autoloading, that when hit checks at runtime "he=
y, this method didn't exist, but is there a `use`d function that would m=
atch based on the runtime type of this value?"  But Ilija felt that woul=
d be prohibitively slow.  It would certainly be slower than just a funct=
ion/method call since the trap takes time.

Yep, this would def have to be done at runtime; not compile time, which =
pretty much rules out `use` as a solution (at least as `use` is currentl=
y implemented). What could happen instead is that it literally patches t=
he class's method table when you define an extension method. This would =
make it globally available once defined; but that is probably fine 99% o=
f the time (since you're most likely the only one using that extension).=
 You could even isolate it to the namespace it is defined in. A solution=
 could be to encode the namespace in the injected method name as a sort =
of mangling.

namespace Foo;

function \OtherNamespace\Point.area(): int {}

// patches OtherNamespace\Point with a method called \Foo\Area()

Or something like that. The main issue is that then it can't be resolved=
 at runtime because namespaces are "erased". You'd have to extract the c=
urrent namespace from the current name which means bare code won't be ab=
le to call it, even if it is in the namespace because bare code is execu=
ted in the global namespace (IIRC): https://3v4l.org/pRsoh

I did quite a bit of experimentation on this for nested classes (which n=
eeded to be able to differentiate between a namespace and a class of the=
 same name). It's not simple.

I don't really have a good solution; so I'm sorry to only bring issues h=
ere. But at least I can name the challenges ahead. Feel free to ask me a=
nything about this.

> And then we get into questions of inheritance, and, well, it gets even=
 messier fast.
>=20
> One possibility that we riffed on during the pipes discussion (mostly =
off list, I think) was using +> for some combination of extension functi=
ons and Elixir-style first-arg pipe passing, so that $p+>area() would si=
gnal to the engine (compile time or runtime) that area() wasn't a method=
 but a function that should get $p passed to it.  That would solve the "=
trap" problem, but still doesn't address autoloading, the lack of compil=
e time type knowledge, or how to differentiate between Point.area(), Sha=
peInterface.area(), Rect.area(), etc.
>=20
> --Larry Garfield

=E2=80=94 Rob
--b9e31c128f8b4739ab5e6e919b79dd96
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, Jun =
10, 2025, at 22:09, Larry Garfield wrote:</div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>On Tue, Jun 10, 2025, at 2:45 PM, Dmitry Dere=
pko wrote:</div><div>&gt; Thanks for participating, Larry.</div><div>&gt=
;</div><div>&gt; On Mon, Jun 9, 2025 at 10:29=E2=80=AFPM Larry Garfield =
&lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>=
&gt; wrote:</div><div>&gt;&gt; 2. Please link to a PR of your actual imp=
lementation.&nbsp; In context it looks like your branch comparison link =
is to the version you said didn't work, so it's not that helpful.</div><=
div>&gt;</div><div>&gt; Correct, I don't have another one. This is big f=
eature, I need a lot of&nbsp;</div><div>&gt; time to implement it. I don=
't want to waste my time if we decide that&nbsp;</div><div>&gt; RFC won'=
t pass at all.</div><div><br></div><div>Understood.</div></blockquote><d=
iv><br></div><div>I'd recommend figuring it out, even if it costs a lot =
of time. Some of the feedback I got on nested classes -- even after work=
ing on the implementation nearly every weekend for months -- was that th=
e PoC code was too hacky and didn't work with opcache. There are hard da=
tes for features to be merged; and if you don't hit that date ... well, =
fun times to be had trying to get it done by the release time, and nobod=
y wants that crunch (and the inevitable bugs that follow). There's enoug=
h to do just to get a release done. Having working code that is at least=
 somewhat shippable is a big indicator that an RFC will pass.</div><div>=
<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div>=
<div>&gt;&gt; 3. The biggest question that has come up in the past (Ilij=
a and I have discussed it at length) is, naturally, autoloading.&nbsp; H=
ow if at all do you address that?</div><div>&gt;</div><div>&gt; In the o=
riginal message I mentioned `use extension` construction. This&nbsp;</di=
v><div>&gt; should be enough for solution, isn't it?</div><div><br></div=
><div>Very much not.&nbsp; The `use` construct has no bearing on autoloa=
ding currently.&nbsp; Autoloading happens only for classes and class-lik=
e things (interfaces, traits, enums).&nbsp; If a function is not found, =
PHP just crashes.&nbsp; Various solutions to this have been discussed ov=
er the years, none of which ever made it as far as a vote.</div><div><br=
></div><div>I toyed with the idea of having extension functions compile =
to a static method on a class as a way around this, but of course then y=
ou end up with a file-per-function, and the file name has to match not t=
he function name, but whatever mangled class name gets generated.&nbsp; =
Not at all intuitive.</div><div><br></div><div>In fairness, I think with=
 universal opcache, preloading, and the increasing use of persistent pro=
cesses, just skipping autoloading for functions and front-loading them v=
ia composer.json's "files" block is fine for the 80% case.&nbsp; But it =
feels like I am in the minority on that position.</div><div><br></div><d=
iv>&gt;&gt; 4. The other big question was determining when to match a gi=
ven "method" call to an extension function, when the type of a variable =
is not always known at compile time.&nbsp; How did you address this?</di=
v><div>&gt;</div><div>&gt; Cannot understand the passage, could you expl=
ain more?</div><div><br></div><div>&lt;?php&nbsp;</div><div>// index.php=
</div><div><br></div><div>function Point.area(): int {&nbsp;</div><div>&=
nbsp; return $this-&gt;x &amp; $this-&gt;y;</div><div>}</div><div><br></=
div><div>function doStuff($p) {</div><div>&nbsp; // At compile time, we =
don't know that $p is a Point. In fact, it may not be.</div><div>&nbsp; =
// The function will allow any value here, even a non-object, so it does=
n't know</div><div>&nbsp; // if this should be compiled to Point__area($=
p) or left as is.</div><div>&nbsp; print $p-&gt;area();</div><div>}</div=
><div><br></div><div>The only way I could think of to handle that is to =
have a method call "trap" similar to class autoloading, that when hit ch=
ecks at runtime "hey, this method didn't exist, but is there a `use`d fu=
nction that would match based on the runtime type of this value?"&nbsp; =
But Ilija felt that would be prohibitively slow.&nbsp; It would certainl=
y be slower than just a function/method call since the trap takes time.<=
/div></blockquote><div><br></div><div>Yep, this would def have to be don=
e at runtime; not compile time, which pretty much rules out `use` as a s=
olution (at least as `use` is currently implemented). What could happen =
instead is that it literally patches the class's method table when you d=
efine an extension method. This would make it globally available once de=
fined; but that is probably fine 99% of the time (since you're most like=
ly the only one using that extension). You could even isolate it to the =
namespace it is defined in. A solution could be to encode the namespace =
in the injected method name as a sort of mangling.</div><div><br></div><=
div>namespace Foo;</div><div><br></div><div>function \OtherNamespace\Poi=
nt.area(): int {}</div><div><br></div><div>// patches OtherNamespace\Poi=
nt with a method called \Foo\Area()</div><div><br></div><div>Or somethin=
g like that. The main issue is that then it can't be resolved at runtime=
 because namespaces are "erased". You'd have to extract the current name=
space from the current name which means bare code won't be able to call =
it, even if it is in the namespace because bare code is executed in the =
global namespace (IIRC):&nbsp;<a href=3D"https://3v4l.org/pRsoh">https:/=
/3v4l.org/pRsoh</a></div><div><br></div><div>I did quite a bit of experi=
mentation on this for nested classes (which needed to be able to differe=
ntiate between a namespace and a class of the same name). It's not simpl=
e.</div><div><br></div><div>I don't really have a good solution; so I'm =
sorry to only bring issues here. But at least I can name the challenges =
ahead. Feel free to ask me anything about this.</div><div><br></div><blo=
ckquote type=3D"cite" id=3D"qt" style=3D""><div>And then we get into que=
stions of inheritance, and, well, it gets even messier fast.</div><div><=
br></div><div>One possibility that we riffed on during the pipes discuss=
ion (mostly off list, I think) was using +&gt; for some combination of e=
xtension functions and Elixir-style first-arg pipe passing, so that $p+&=
gt;area() would signal to the engine (compile time or runtime) that area=
() wasn't a method but a function that should get $p passed to it.&nbsp;=
 That would solve the "trap" problem, but still doesn't address autoload=
ing, the lack of compile time type knowledge, or how to differentiate be=
tween Point.area(), ShapeInterface.area(), Rect.area(), etc.</div><div><=
br></div><div>--Larry Garfield<br></div></blockquote><div><br></div><div=
 id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--b9e31c128f8b4739ab5e6e919b79dd96--