Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131030
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
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 06:02:50 +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>
To: internals@lists.php.net
In-Reply-To: <20260528023149.C97961A00BD@lists.php.net>
Message-ID: <76D39851-7DAC-4F56-9615-B98B0A918770@gmail.com>
From: hmennen90@gmail.com (Hendrik Mennen)



> Am 28.05.2026 um 04:31 schrieb Ben Ramsey <ramsey@php.net>:
>=20
> On 5/27/26 09:27, Hendrik Mennen wrote:
>>> Am 27.05.2026 um 15:19 schrieb Ben Ramsey <ramsey@php.net>:
>>>=20
>>> The problem with assigning meaning to a file extension is that the
>>> interpreter (currently) doesn't care what the file extension is. As =
long
>>> as it's text, it'll process any file and execute what comes after =
any
>>> <?php tags.
>> Right, that is the current behavior, and changing it is exactly what =
the proposal is about. The engine would learn to check the file =
extension at the entry point (zend_compile_file for SAPI/CLI, and the =
include/require family for nested loads) and use that to set the initial =
lexer state. The .php behavior remains untouched.
>=20
>=20
> The behavior right now is that the file extension isn't checked. So, =
whether it's .php, .phtml, .php3, .rb, .py, or .txt doesn't matter. =
Using .php is a convention, not a requirement. If the proposal places =
any restrictions on the file extension, that's a major BC break.
>=20
> So, the logic will need to be something like: if .phpc, then parse =
assuming there are no <?php tags, otherwise assume there must be <?php =
tags.
>=20
>=20
>> That said, you point indirectly at something I do need to address: =
there are entry paths where the engine does not have a filename, or has =
one it should not trust. Off the top of my head:
>> - stdin (cat foo.phpc | php). No filename available. Options: require =
an explicit CLI flag (php --pure), or simply not support this path and =
document it.
>> - eval(). Operates on strings, not files. Extension is irrelevant =
here; eval() continues to require <?php as today.
>> - Phar archives. Internal entries have filenames, so dispatch by =
extension should work, but I would need to verify.
>> - include of a URL stream (rare, often disabled). Same question. =
Probably handled by extension on the URL path.
>> I will work these out explicitly in the RFC draft. Thanks for =
surfacing it.
>>> At the risk of bike-shedding, I think it could be easy for others to
>>> confuse .phpc files as byte-code files, since it's common to see =
Python
>>> byte-code files with the .pyc extension.
>> Fair point, and one I had not weighed heavily enough. The Python .pyc =
parallel is real and would cause exactly the kind of one-time confusion =
that adds friction to adoption. Boutell's 2012 RFC used .phpp (Pure PHP) =
for the same purpose, which avoids the bytecode association. I am open =
to .phpp or other suggestions; the disambiguator matters less than the =
mechanism.
>=20
>=20
> I'm still unsure about assigning any meaning to the extension. Maybe =
this is something that could be handled at the SAPI configuration level =
similar to how .phps files are configured? Likewise, maybe the CLI =
should have a `-p` flag that tells it to process the input without =
checking for <?php tags.
>=20
> For what it's worth, `php foo.phps` still executes the file. You need =
to run `php -s foo.phps` to output HTML syntax-highlighted source. The =
.phps extension has no meaning to the interpreter.
>=20
> That said, I'm not sure how you'd handle this with include/require or =
in Phar files.
>=20
>=20
> Cheers,
> Ben


Hi Ben,

> I'm still unsure about assigning any meaning to the extension. Maybe
> this is something that could be handled at the SAPI configuration
> level similar to how .phps files are configured?

Thanks, and also thanks for the correction on .phps. I had the wrong =
mental model there: I assumed the extension carried interpreter meaning, =
when in fact it is purely an Apache handler convention plus the php -s =
flag. Useful to have that straight before drafting.

That said, SAPI-level configuration is exactly the path I do not think =
can carry the full mechanism, and I think your own observation at the =
end of your mail is the reason:

> That said, I'm not sure how you'd handle this with include/require or
> in Phar files.

Right, and this is the crux. include, require, and Phar entry resolution =
all happen below the SAPI layer, inside the engine. A web server handler =
mapping .phpc to a pure-code mode would work for the directly-served =
entry file, but the moment that file does require __DIR__ . =
'/lib/something.phpc', the engine has to decide what to do with the =
included file on its own, with no SAPI in the loop. The same applies to =
CLI: php script.php works through one path, php -f script.php through =
another, both bypassing any web-server config. And Phar internals never =
see SAPI at all.

So I think the dispatch has to live in the engine. The extension is just =
the most ergonomic signal I can think of for the engine to use, but I am =
open to other engine-level signals (a magic first line, a declare-like =
marker, even a per-Phar manifest flag). What I do not think works is =
delegating the decision to layers above the engine, because those layers =
do not cover all entry paths.

> Likewise, maybe the CLI should have a -p flag that tells it to process
> the input without checking for <?php tags.

This I would take, as a complement rather than a replacement. The stdin =
case (cat foo | php) is exactly where there is no filename to inspect, =
and a -p flag is a clean way to handle it. I will include this in the =
draft as the explicit answer to the stdin entry path.

Would you find the proposal more palatable if the RFC framed the =
extension dispatch as one of several engine-level signals (with the =
extension being the recommended default, but a declare-style marker or a =
CLI flag covering the cases where extension is unavailable), rather than =
as the sole mechanism? I am trying to understand whether your objection =
is to extension-based dispatch specifically, or to the broader idea of =
the engine making this decision at all.

Hendrik Mennen
Maintainer, PHPolygon