Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131032
Content-Type: multipart/alternative;
 boundary="------------k5egc329tgrRqg1NET8Y467c"
Message-ID: <690e2bc4-d6c9-488b-bbd7-0010437f6c15@gmail.com>
Date: Thu, 28 May 2026 08:36:15 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Pre-RFC] Pure-code source files via .phpc extension
To: internals@lists.php.net
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>
Content-Language: fr
In-Reply-To: <20260528043224.2CDD51A00BD@lists.php.net>
From: pierstoval@gmail.com (Alex Rock)

This is a multi-part message in MIME format.
--------------k5egc329tgrRqg1NET8Y467c
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Le 28/05/2026 à 06:32, Ben Ramsey a écrit :
> On 5/27/26 23:02, Hendrik Mennen wrote:
>>
>> 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.
>>
>
> I don't have a strong objection to the engine making this decision, but
> I'd like to hear from others first.
>
> Cheers,
> Ben


I think this can be summarised with this:

  * 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.

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=0|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.

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.

WDYT?

--------------k5egc329tgrRqg1NET8Y467c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 28/05/2026 à 06:32, Ben Ramsey a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:20260528043224.2CDD51A00BD@lists.php.net">On 5/27/26
      23:02, Hendrik Mennen wrote:
      <br>
      <blockquote type="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 <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 <i>might</i> 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=0|1" , or similar, TDB anyway), and would only be
      used for <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>
  </body>
</html>

--------------k5egc329tgrRqg1NET8Y467c--