Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131033
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D8494FEC-9E0F-4B6C-8726-BDE8B52B8E97"
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 10:39:33 +0200
References: <DD0DF2CC-1F18-A844-B7B8-B00FA2679A47@hxcore.ol>
 <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol>
 <20260527131921.086BB1A00BD@lists.php.net>
 <8AE9A269-2E40-42F0-A0F8-C6690B2935FE@gmail.com>
 <20260528023149.C97961A00BD@lists.php.net>
 <76D39851-7DAC-4F56-9615-B98B0A918770@gmail.com>
 <20260528043224.2CDD51A00BD@lists.php.net>
 <690e2bc4-d6c9-488b-bbd7-0010437f6c15@gmail.com>
To: internals@lists.php.net
In-Reply-To: <690e2bc4-d6c9-488b-bbd7-0010437f6c15@gmail.com>
Message-ID: <878E83EF-DBA2-429A-A17B-55238600E834@gmail.com>
From: hmennen90@gmail.com (Hendrik Mennen)


--Apple-Mail=_D8494FEC-9E0F-4B6C-8726-BDE8B52B8E97
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Am 28.05.2026 um 08:36 schrieb Alex Rock <pierstoval@gmail.com>:
>=20
> Le 28/05/2026 =C3=A0 06:32, Ben Ramsey a =C3=A9crit :
>> On 5/27/26 23:02, Hendrik Mennen wrote:
>>>=20
>>> I am trying to understand whether your objection is to extension-=20
>>> based dispatch specifically, or to the broader idea of the engine=20
>>> making this decision at all.=20
>>>=20
>>=20
>> I don't have a strong objection to the engine making this decision, =
but=20
>> I'd like to hear from others first.=20
>>=20
>> Cheers,=20
>> Ben=20
>=20
> I think this can be summarised with this:
>=20
> File extension cannot have a "meaning" for the engine, as the engine =
does not care about it at all in the first place
> All SAPIs will consider a "normal PHP file" as default input, could it =
be CLI, mod_php for Apache, or anything else (even FrankenPHP)
> IMO this means that the default entrypoint for "parsing and executing =
PHP files" for all SAPIs must not change, but might either be =
complemented with a boolean arg for "pure PHP"/"no <?php ?> tags" , or =
the engine must provide another public entrypoint for this that SAPIs =
could implement or not.
>=20
> An environment variable could be even used for that, and be included =
in the engine by default, so that all existing SAPIs could be updated at =
lower cost, but the variable name would have to be checked in all =
existing Composer packages (something like "PHP_INPUT_PURE=3D0|1" , or =
similar, TDB anyway), and would only be used for first included file. =
Any subsequent call to "include/require" would still behave as before, =
to avoid BC breaks.
>=20
> And after that, to make use of this feature in userland projects, I =
would suggest an "include_pure" (and its "require" + "_once" variants) =
global keyword, to keep full compatibility everywhere.
>=20
> WDYT?
>=20

Hi Alex,

Thanks for jumping in with concrete alternatives. Let me address each, =
because I think the most important thing for the RFC draft is to be =
precise about what the actual constraints are versus what is just the =
current default.

> * File extension cannot have a "meaning" for the engine, as the engine
>   does not care about it at all in the first place

I would push back on this gently, because I think it is a description of =
current behavior, not a constraint. The engine does have the filename =
available in zend_compile_file and in the include/require resolution =
path. Teaching it to check the extension there is a small, additive =
change, not a violation of any architectural rule I am aware of. Other =
languages do this routinely (Python differentiates .py from .pyc at the =
loader level). So the question is not "can the engine know about =
extensions" but "should we use that as the signal here." Happy to be =
told there is an architectural reason I am missing, but if the objection =
is just "this is not how PHP does it today," then the whole RFC is by =
definition asking to change that.

> * All SAPIs will consider a "normal PHP file" as default input, could
>   it be CLI, mod_php for Apache, or anything else (even FrankenPHP)

Agreed, and nothing in the proposal changes that. Existing .php files =
behave exactly as today through every SAPI. The proposal is additive: a =
new file type that the engine handles differently, with zero impact on =
the existing default path.

> An environment variable could be even used for that, [...] and would
> only be used for *first included file*. Any subsequent call to
> "include/require" would still behave as before, to avoid BC breaks.

This is where I see a real problem with the env-var approach. If only =
the entry file is pure and everything it includes must be mixed-mode, =
then pure code cannot be shipped as a library. A library author writing =
pure code could never be loaded from a mixed-mode application, and vice =
versa. The adoption story dies on contact with Composer.

For pure-code files to be useful in practice, the parsing context has to =
attach to the file itself, not to the entry-point execution. Otherwise =
the feature is limited to a single bootstrap script, which is too narrow =
to justify the engine change.

> And after that, to make use of this feature in userland projects, I
> would suggest an "include_pure" (and its "require" + "_once" variants)
> global keyword

This is essentially Tom Boutell's 2012 approach =
(rfc/source_files_without_opening_tag), which used a modified include =
syntax. Boutell ultimately abandoned that RFC, citing concerns that I =
would summarize as: the caller decides how the file is parsed, not the =
author. That inverts the usual relationship between a library and its =
consumer. A library author cannot ship pure-code files with the =
guarantee that they will be parsed as such, because consumers might =
forget include_pure and load them with regular include. The same =
physical file would parse differently depending on how it was loaded, =
which is a discoverability and tooling nightmare.

That said, I do not want to dismiss include_pure entirely. As a =
complement to extension-based dispatch, it has merit:

- For stdin and eval-like situations, where no filename exists, an =
explicit per-call signal is exactly what is needed (Ben suggested php -p =
for the CLI stdin case, similar idea).
- For interop scenarios where someone wants to force pure-code parsing =
on a file that does not have the extension, it provides an explicit =
escape hatch.

What I think does not work is replacing the extension-based mechanism =
with include_pure, because then we lose the "file declares its own =
parsing context" property.

A possible synthesis:

1. Primary mechanism: file extension (the file itself declares its =
parsing context, author-controlled).
2. CLI complement: -p flag for stdin (Ben's suggestion).
3. Userland complement: include_pure or similar for explicit override =
(your suggestion, but as override not primary).

This gives every entry path a clear answer and keeps author intent =
intact. I will work this into the RFC draft.

Does the engine-level dispatch via extension still feel wrong to you =
once the alternative is framed this way, or is your objection more =
specific to the .phpc letter than to the mechanism?

Hendrik Mennen
Maintainer, PHPolygon=

--Apple-Mail=_D8494FEC-9E0F-4B6C-8726-BDE8B52B8E97
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 08:36 schrieb Alex Rock =
&lt;pierstoval@gmail.com&gt;:</div><br =
class=3D"Apple-interchange-newline"><div>

 =20
    <meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3DUTF-8">
 =20
  <div>
    <div class=3D"moz-cite-prefix">Le 28/05/2026 =C3=A0 06:32, Ben =
Ramsey a
      =C3=A9crit&nbsp;:<br>
    </div>
    <blockquote type=3D"cite" =
cite=3D"mid:20260528043224.2CDD51A00BD@lists.php.net">On 5/27/26
      23:02, Hendrik Mennen wrote:
      <br>
      <blockquote type=3D"cite">
        <br>
        I am trying to understand whether your objection is to
        extension-
        <br>
        based dispatch specifically, or to the broader idea of the
        engine
        <br>
        making this decision at all.
        <br>
        <br>
      </blockquote>
      <br>
      I don't have a strong objection to the engine making this
      decision, but
      <br>
      I'd like to hear from others first.
      <br>
      <br>
      Cheers,
      <br>
      Ben&nbsp;<br>
    </blockquote><p><br>
    </p><p>I think this can be summarised with this:</p>
    <ul>
      <li>File extension cannot have a "meaning" for the engine, as the
        engine does not care about it at all in the first place</li>
      <li>All SAPIs will consider a "normal PHP file" as default input,
        could it be CLI, mod_php for Apache, or anything else (even
        FrankenPHP)</li>
    </ul><p>IMO this means that the default entrypoint for "parsing and
      executing PHP files" for all SAPIs must not change, =
but&nbsp;<i>might</i>&nbsp;either
      be complemented with a boolean arg for "pure PHP"/"no &lt;?php
      ?&gt; tags" , or the engine must provide another public entrypoint
      for this that SAPIs could implement or not.</p><p>An environment =
variable could be even used for that, and be
      included in the engine by default, so that all existing SAPIs
      could be updated at lower cost, but the variable name would have
      to be checked in all existing Composer packages (something like
      "PHP_INPUT_PURE=3D0|1" , or similar, TDB anyway), and would only =
be
      used for&nbsp;<b>first included file</b>. Any subsequent call to
      "include/require" would still behave as before, to avoid BC
      breaks.</p><p>And after that, to make use of this feature in =
userland projects,
      I would suggest an "include_pure" (and its "require" + "_once"
      variants) global keyword, to keep full compatibility =
everywhere.</p><p>WDYT?</p></div></div></blockquote></div><div>Hi =
Alex,</div><div><br></div><div>Thanks for jumping in with concrete =
alternatives. Let me address each, because I think the most important =
thing for the RFC draft is to be precise about what the actual =
constraints are versus what is just the current =
default.</div><div><br></div><div>&gt; * File extension cannot have a =
"meaning" for the engine, as the engine</div><div>&gt; &nbsp; does not =
care about it at all in the first place</div><div><br></div><div>I would =
push back on this gently, because I think it is a description of current =
behavior, not a constraint. The engine does have the filename available =
in zend_compile_file and in the include/require resolution path. =
Teaching it to check the extension there is a small, additive change, =
not a violation of any architectural rule I am aware of. Other languages =
do this routinely (Python differentiates .py from .pyc at the loader =
level). So the question is not "can the engine know about extensions" =
but "should we use that as the signal here." Happy to be told there is =
an architectural reason I am missing, but if the objection is just "this =
is not how PHP does it today," then the whole RFC is by definition =
asking to change that.</div><div><br></div><div>&gt; * All SAPIs will =
consider a "normal PHP file" as default input, could</div><div>&gt; =
&nbsp; it be CLI, mod_php for Apache, or anything else (even =
FrankenPHP)</div><div><br></div><div>Agreed, and nothing in the proposal =
changes that. Existing .php files behave exactly as today through every =
SAPI. The proposal is additive: a new file type that the engine handles =
differently, with zero impact on the existing default =
path.</div><div><br></div><div>&gt; An environment variable could be =
even used for that, [...] and would</div><div>&gt; only be used for =
*first included file*. Any subsequent call to</div><div>&gt; =
"include/require" would still behave as before, to avoid BC =
breaks.</div><div><br></div><div>This is where I see a real problem with =
the env-var approach. If only the entry file is pure and everything it =
includes must be mixed-mode, then pure code cannot be shipped as a =
library. A library author writing pure code could never be loaded from a =
mixed-mode application, and vice versa. The adoption story dies on =
contact with Composer.</div><div><br></div><div>For pure-code files to =
be useful in practice, the parsing context has to attach to the file =
itself, not to the entry-point execution. Otherwise the feature is =
limited to a single bootstrap script, which is too narrow to justify the =
engine change.</div><div><br></div><div>&gt; And after that, to make use =
of this feature in userland projects, I</div><div>&gt; would suggest an =
"include_pure" (and its "require" + "_once" variants)</div><div>&gt; =
global keyword</div><div><br></div><div>This is essentially Tom =
Boutell's 2012 approach (rfc/source_files_without_opening_tag), which =
used a modified include syntax. Boutell ultimately abandoned that RFC, =
citing concerns that I would summarize as: the caller decides how the =
file is parsed, not the author. That inverts the usual relationship =
between a library and its consumer. A library author cannot ship =
pure-code files with the guarantee that they will be parsed as such, =
because consumers might forget include_pure and load them with regular =
include. The same physical file would parse differently depending on how =
it was loaded, which is a discoverability and tooling =
nightmare.</div><div><br></div><div>That said, I do not want to dismiss =
include_pure entirely. As a complement to extension-based dispatch, it =
has merit:</div><div><br></div><div>- For stdin and eval-like =
situations, where no filename exists, an explicit per-call signal is =
exactly what is needed (Ben suggested php -p for the CLI stdin case, =
similar idea).</div><div>- For interop scenarios where someone wants to =
force pure-code parsing on a file that does not have the extension, it =
provides an explicit escape hatch.</div><div><br></div><div>What I think =
does not work is replacing the extension-based mechanism with =
include_pure, because then we lose the "file declares its own parsing =
context" property.</div><div><br></div><div>A possible =
synthesis:</div><div><br></div><div>1. Primary mechanism: file extension =
(the file itself declares its parsing context, =
author-controlled).</div><div>2. CLI complement: -p flag for stdin =
(Ben's suggestion).</div><div>3. Userland complement: include_pure or =
similar for explicit override (your suggestion, but as override not =
primary).</div><div><br></div><div>This gives every entry path a clear =
answer and keeps author intent intact. I will work this into the RFC =
draft.</div><div><br></div><div>Does the engine-level dispatch via =
extension still feel wrong to you once the alternative is framed this =
way, or is your objection more specific to the .phpc letter than to the =
mechanism?</div><div><br></div><div>Hendrik Mennen</div><div>Maintainer, =
PHPolygon</div></body></html>=

--Apple-Mail=_D8494FEC-9E0F-4B6C-8726-BDE8B52B8E97--