Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131041
Message-ID: <06617C42-EA74-4369-BF6E-0DA8CDC225A2@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_169B099E-5333-464A-96F5-1E34D05E5BEC"
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: [PHP-DEV] [Pre-RFC] Pure-code source files via .phpc extension
Date: Thu, 28 May 2026 20:08:21 +0200
In-Reply-To: <671b98c9-b3dc-47d7-84ae-dfba1efa0e26@app.fastmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: mjec <php@mjec.net>
References: <DD0DF2CC-1F18-A844-B7B8-B00FA2679A47@hxcore.ol>
 <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol>
 <CAEUnE0c3rmxzp1jPRhJK678J+hsHOXuL79cHpkx7fX50e_Ak5A@mail.gmail.com>
 <11B6D9B0-2555-4FC4-B540-71680315589F@gmail.com>
 <671b98c9-b3dc-47d7-84ae-dfba1efa0e26@app.fastmail.com>
From: hmennen90@gmail.com (Hendrik Mennen)


--Apple-Mail=_169B099E-5333-464A-96F5-1E34D05E5BEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Am 28.05.2026 um 19:14 schrieb mjec <php@mjec.net>:
>=20
> I'm not a voter, but I have thoughts.
>=20
> On Thu, 2026-05-28 at 11:35 -04:00, Hendrik Mennen =
<hmennen90@gmail.com <mailto:hmennen90@gmail.com>> wrote:
>> > 1. Extension based parsing isn't a popular idea. The first few
>> >    responses to this have echoed this, but there's a certain power =
in
>> >    allowing the parser to not care about the extension.
>>=20
>> Fair, and I have heard this from both Ben and Alex earlier in the =
thread. My pushback there has been that the engine already has the =
filename available at zend_compile_file and at include/require =
resolution, so teaching it to check the extension is additive rather =
than architecturally violating.
>=20
> It's not purely additive. It's taking a thing that currently has no =
semantics (filename) and giving it semantics. Without this change, users =
are able to choose the semantics of the filename by choosing how to =
invoke the interpreter. After this change, that is no longer guaranteed =
to be the user's choice.
>=20
>> That said, as a complementary mechanism for explicit override or for =
stdin/eval cases where no filename exists, a require_pure or =
require_module-style call is genuinely useful. I floated this in my =
reply to Alex as part of a synthesis: extension as primary signal, CLI =
-p flag for stdin (Ben's suggestion), require_pure-family for explicit =
override (your and Alex's suggestion). The autoloader question gets =
simpler in that synthesis because the autoloader can dispatch on =
extension by default.
>=20
> Even ignoring the `include` issue, this is more evidence to me that =
the trigger for this mechanism should not live in the filename. Let =
users choose an invocation path (SAPI configuration) based on filename =
if they want, but do not make it a language feature.
>=20
>> > 4. PHP has several braceless syntax control structure commands - =
Would
>> >    these stay around or should they too go away since they aren't
>> >    really needed in a code first file.
> ...
>> Two reasonable positions:
> ...
>> (b) Disallow it. The new file format has the freedom to be stricter, =
and the alternative syntax serves no purpose without templating.
>=20
> This would be a big change from the original proposal, which was =
"pars[ing] starting in ST_IN_SCRIPTING". This is not just talking about =
skipping `<?php`, you're talking about defining new syntax rules. As you =
discuss, this is an enormous can of worms, and I wouldn't want it to be =
tacked onto something that has a different primary purpose. To be honest =
I would not consider this a reasonable position on this RFC.
>=20
>> The accidental-echo / headers-already-sent issue is the real =
practical win. That bug class disappears entirely in pure-code files. I =
would list this as the second motivation in the RFC after the conceptual =
one.
>=20
> I don't think of this issue as big enough to require a language =
feature. You can already check for this condition with a one-liner =
without any additional tooling:
>=20
> php -r 'echo =
empty(array_filter(token_get_all(file_get_contents("/path/to/file.php")), =
fn($t) =3D> $t[0] =3D=3D=3D T_INLINE_HTML)) ? "OK\n" : "Contains =
non-PHP!";'
>=20
> And finally, Hendrik while I appreciate your detailed replies, they =
are clearly LLM-patterned, and that makes me disinclined to read them. I =
understand if you want help crafting the words you use, but I just don't =
really believe you would have said anything like "[t]his is the most =
important point you raised and I want to be careful with it" (for =
example) if that hadn't come from an LLM. That means you're =
communicating its judgement, not your own. I do not want to start a =
discussion on this topic, merely to express my view.
>=20
> mjec
>=20

Hi mjec,

Thanks for your mention about LLM usage - yes I use LLM in my daily work =
but I=E2=80=99m also a developer at senior level with 10 years of =
experience - much less than most others :-)

I=E2=80=99m fairly new to PHP Core / Extension development - that=E2=80=99=
s right. I don=E2=80=99t trust LLM output blindly.


Because of your point =E2=80=9E4. PHP has several braceless syntax =
control structure commands

Yeah - this was out of scope for this RFC but I wanted to address it. - =
The core of my intention is clear the option to get rid of <?php and ?>

Hendrik=

--Apple-Mail=_169B099E-5333-464A-96F5-1E34D05E5BEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Am 28.05.2026 um 19:14 schrieb mjec =
&lt;php@mjec.net&gt;:</div><br =
class=3D"Apple-interchange-newline"><div><title></title><div><div>I'm =
not a voter, but I have thoughts.</div><div><br></div><div>On Thu, =
2026-05-28 at 11:35 -04:00, Hendrik Mennen &lt;<a =
href=3D"mailto:hmennen90@gmail.com">hmennen90@gmail.com</a>&gt; =
wrote:<br></div><blockquote type=3D"cite" id=3D"qt" =
style=3D"overflow-wrap:break-word;"><div><div>&gt; 1. Extension based =
parsing isn't a popular idea. The first few</div><div>&gt; &nbsp; =
&nbsp;responses to this have echoed this, but there's a certain power =
in</div><div>&gt; &nbsp; &nbsp;allowing the parser to not care about the =
extension.</div><div><br></div><div>Fair, and I have heard this from =
both Ben and Alex earlier in the thread. My pushback there has been that =
the engine already has the filename available at zend_compile_file and =
at include/require resolution, so teaching it to check the extension is =
additive rather than architecturally =
violating.</div></div></blockquote><div><br></div><div>It's not purely =
additive. It's taking a thing that currently has no semantics (filename) =
and giving it semantics. Without this change, users are able to choose =
the semantics of the filename by choosing how to invoke the interpreter. =
After this change, that is no longer guaranteed to be the user's =
choice.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" =
style=3D"overflow-wrap:break-word;"><div><div>That said, as a =
complementary mechanism for explicit override or for stdin/eval cases =
where no filename exists, a require_pure or require_module-style call is =
genuinely useful. I floated this in my reply to Alex as part of a =
synthesis: extension as primary signal, CLI -p flag for stdin (Ben's =
suggestion), require_pure-family for explicit override (your and Alex's =
suggestion). The autoloader question gets simpler in that synthesis =
because the autoloader can dispatch on extension by =
default.</div></div></blockquote><div><br></div><div>Even ignoring the =
`include` issue, this is more evidence to me that the trigger for this =
mechanism should not live in the filename. Let users choose an =
invocation path (SAPI configuration) based on filename if they want, but =
do not make it a language feature.</div><div><br></div><blockquote =
type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div><div>&gt;=
 4. PHP has several braceless syntax control structure commands - =
Would</div><div>&gt; &nbsp; &nbsp;these stay around or should they too =
go away since they aren't</div><div>&gt; &nbsp; &nbsp;really needed in a =
code first file.</div></div></blockquote><div>...</div><blockquote =
type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div><div>Two =
reasonable positions:</div></div></blockquote><div>...</div><blockquote =
type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div><div>(b) =
Disallow it. The new file format has the freedom to be stricter, and the =
alternative syntax serves no purpose without =
templating.</div></div></blockquote><div><br></div><div>This would be a =
big change from the original proposal, which was "pars[ing] starting in =
ST_IN_SCRIPTING". This is not just talking about skipping `&lt;?php`, =
you're talking about defining new syntax rules. As you discuss, this is =
an enormous can of worms, and I wouldn't want it to be tacked onto =
something that has a different primary purpose. To be honest I would not =
consider this a reasonable position on this =
RFC.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" =
style=3D"overflow-wrap:break-word;"><div><div>The accidental-echo / =
headers-already-sent issue is the real practical win. That bug class =
disappears entirely in pure-code files. I would list this as the second =
motivation in the RFC after the conceptual =
one.</div></div></blockquote><div><br></div><div>I don't think of this =
issue as big enough to require a language feature. You can already check =
for this condition with a one-liner without any additional =
tooling:</div><div><br></div><div>php -r 'echo =
empty(array_filter(token_get_all(file_get_contents("/path/to/file.php")), =
fn($t) =3D&gt; $t[0] =3D=3D=3D T_INLINE_HTML)) ? "OK\n" : "Contains =
non-PHP!";'<br></div><div><br></div><div>And finally, Hendrik while I =
appreciate your detailed replies, they are clearly LLM-patterned, and =
that makes me disinclined to read them. I understand if you want help =
crafting the words you use, but I just don't really believe you would =
have said anything like "[t]his is the most important point you raised =
and I want to be careful with it" (for example) if that hadn't come from =
an LLM. That means you're communicating its judgement, not your own. I =
do not want to start a discussion on this topic, merely to express my =
view.</div><div><br></div><div>mjec</div><div><br></div></div></div></bloc=
kquote></div><br><div>Hi mjec,</div><div><br></div><div>Thanks for your =
mention about LLM usage - yes I use LLM in my daily work but I=E2=80=99m =
also a developer at senior level with 10 years of experience - much less =
than most others :-)</div><div><br></div><div>I=E2=80=99m fairly new to =
PHP Core / Extension development - that=E2=80=99s right. I don=E2=80=99t =
trust LLM output =
blindly.</div><div><br></div><div><br></div><div>Because of your point =
=E2=80=9E4. PHP has several braceless syntax control structure =
commands</div><div><br></div><div>Yeah - this was out of scope for this =
RFC but I wanted to address it. - The core of my intention is clear the =
option to get rid of &lt;?php and =
?&gt;</div><div><br></div><div>Hendrik</div></body></html>=

--Apple-Mail=_169B099E-5333-464A-96F5-1E34D05E5BEC--