Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:131043 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id B3DC71A00BC for ; Thu, 28 May 2026 20:57:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1780001843; bh=3mZJcN4hLTrag8f7UMFZfXH31PCeNBZ3p89HVW3sxD8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=DkdT98LILC3dGwVOmniieXfEttfZqo0Z8j1VbTboeK3hIVR3B/OQ3L6S4j9GRp/bc +Upf100BnWPjwYt5Gak21jE+gcmG6OQJLxMPdGa+CyibMIYAtbe3P3hGtxSeANX19c +054qdF4aMOpttQ/3FUyZWWuaocWXYnH1u3uAmBlQsG0a5AYnVwgnYmf+T4qUMQX9j LF/HqGGtguls9qHOrJ52gz2jADfPAkC4FRrlf+x2lqQy9uxOjfvmdGjElQOSgAggrF R2ffODexuJtp52XtgU1Fz2f5IqzLxeMXOF3MUWJRy0nco1iOhRBSEOUbjpOv1k2071 Yf46DkDIOnTCA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 27A7C180040 for ; Thu, 28 May 2026 20:57:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, T_SPF_TEMPERROR autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 28 May 2026 20:57:15 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6896c54a7easo4434192a12.3 for ; Thu, 28 May 2026 13:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780001830; x=1780606630; darn=lists.php.net; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=eLfiEXoB4UYduJhi50qPtJbzXaYqHV7i5NMUZjve+hM=; b=bS8LcW6jv6VlMrgQdBzdraOoBurZnN0KRmeFVWvzoRfO36iskvzKhX7j6eVouOsB4A 1eAvBdPxPHX5SXT0Epp8kSGWVpTZL/0QVbD80ObVJ4g+gXxbtDpe3JAkCvJfCbSJavyS cP35PeK4E0D3jh1j0Tco674SOReyDlWpN1Y19BciHBPwJK1IWG7bIzTJuMm1Ml504stw QuTKZOjQUI/yC6YgQ1vpyduqYvwX1lY6Xk3Uv/6gSgEF7odQP37bVsjS09ylPC5Cfm12 CD8YgPes3oBgLnrRrCu18yGzX2oZyVPMBiKL4bVhrVLXITN9grIcRW32WZ9H0Tf1sFRa Hphw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780001830; x=1780606630; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eLfiEXoB4UYduJhi50qPtJbzXaYqHV7i5NMUZjve+hM=; b=Yj7caBAZIA5orTWzF8BwD2vGWe5n0O69kauBfJb1Mfz5kLZRT83gb9HJR41l/45Jtr dWRbsZCQ35UhkUB6Ba03WAa36Humsvli1S17gTW13QzP+tUUeA8hHUC7R1wemH/S9BPY ttd5j+yi+dW7T7uKGTicHOnpmngB+z/xl8VMkabg7JHtAFz5PJn2632mTaeU6u1H7ZU4 DcXCvC6x5ETsT/MDdPNfzuPjSjcFxTd/Enag/DmLV09LNj8Ih6MaheIWQLCJGNCA00Hw lSQj/5kF+UgG092zvdc+kQ/5durEmJ53E07toku68xpr+ncqqXYLjF1JKYoXqTjSynWc rncA== X-Gm-Message-State: AOJu0Yxu+rHSLEjTvgM8DueBD+8oKUmpxFZJ0AcdG1pfFa9iJO9v8bGX 4vKIlL/bejB15X+pPMKiFbpdqjXAlv7mdnUihcIg/70LexaenQ4drIOose2NOg== X-Gm-Gg: Acq92OE6WEcVGCIoNIPZx9cNQlyh8GXPtE+gENZ3d0z/QRU7SHY1/zvPo9iVktXTWs+ WjS27kkPeFh+i3igHN8yW5cfPuHdycCD1FGb2jxoCR3wiPgm5DGDn9z+FZP/oCOFbfg7CgsE5/T MO2/l3skda+x4mvGnclsRl8s1iXhjF+Y086fwi18BShVJHA6EsO4isVitdGkpyJsA/5I9O1BPnp b9evpvRafkg95IzgDieC7bm+jfDZvd3Uuk/hGVJn5KYSArAFsVdnzaPaV54kaf7R71E/UQVdPW9 fPibMeb9tEDgtRqxipkIw+yZwN+usVTwbPNljOgSrZYKfrL67t3fQwbh5s0Jaf5AaflOq+efqlg hwiogrGHicfipLaHUAwKl5rPfefZ58kTbEsINlaOpFrcNuUyPGzFKSSnN+v0pi76c7ck+kCVd2N rX6vFh10eGmCdG6KpkJ1+gu6siEsqfvedavyvSapGD60lIOk5UUEHmLD81IkJDwohG X-Received: by 2002:a05:6402:3511:b0:686:9c15:3121 with SMTP id 4fb4d7f45d1cf-68bfb309abbmr150210a12.12.1780001829578; Thu, 28 May 2026 13:57:09 -0700 (PDT) Received: from [192.168.0.3] ([94.147.148.52]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-68a6fa2a017sm2330813a12.0.2026.05.28.13.57.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2026 13:57:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------zU0vgBlEclqaMncE079zTnvs" Message-ID: Date: Thu, 28 May 2026 22:57:07 +0200 Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] AW: [Pre-RFC] Pure-code source files via .phpc extension To: internals@lists.php.net References: <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol> Content-Language: en-GB In-Reply-To: <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol> From: henry.wood.dk@gmail.com (Henrik Skov) This is a multi-part message in MIME format. --------------zU0vgBlEclqaMncE079zTnvs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi internals ! I fail to see the upside ? What does such a feature provide as an upside to users ? Is it performance only ? The performance gain would be negible wouldn't it ? /Henrik On 27/05/2026 14.12, hmennen90@gmail.com wrote: > Hi internals, > > I intend to submit an RFC introducing a new file extension for > pure-code PHP source files (no leading to gather feedback before drafting. > > Proposal in brief: > > Files ending in .phpc would be parsed starting in ST_IN_SCRIPTING > state. No tags permitted inside such files. Existing .php > files and their semantics are completely unchanged. This is purely > additive and BC-clean. > > Motivation: > > PHP's mixed-mode default reflects its 1995 templating origins. Since > PHP 7+, the language has evolved into a credible general-purpose tool: > strict types, enums, readonly classes, property hooks, JIT > compilation. I personally maintain PHPolygon, a CPU-bound 3D engine > written in PHP – a use case where the templating heritage is pure > ceremony. Other modern uses (CLI tooling, queue workers, code > generators) share this pattern. A dedicated pure-code file format > would be a small but meaningful acknowledgment that PHP-as-language is > now a first-class use case alongside PHP-as-template. > > Prior art and what's different: > > I have read both rfc/source_files_without_opening_tag (Boutell, 2012, > abandoned by author) and rfc/nophptags (Ohgaki, 2014, inactive). My > proposal deliberately avoids what I believe were the two design > choices that killed them: > > - No new include syntax (Boutell's AS keyword). Extension-based > detection only. > - No php.ini-based mode switch (Ohgaki's template_mode). No global > config side effects. > - No security framing. The mode-switch overhead is parse-time only and > OPcache/JIT eliminate it in practice; this proposal is about > conceptual clarity and tooling, not performance or LFI mitigation. > > Implementation: > > I will write and maintain the implementation patch. Initial scope: > extension registration in zend_compile_file, lexer state > initialization, OPcache awareness, CLI support, and rejection of > tokens inside .phpc files. I will also coordinate with > Composer maintainers ahead of RFC submission to confirm autoload support. > > Open questions for the list: > > 1. Is the .phpc extension acceptable as the disambiguator, or is there > appetite for something else (e.g. shebang line, declare directive – > both of which I think are worse, but I'd hear the case)? > 2. Should #! shebang lines and UTF-8 BOM be permitted before the > implicit scripting state begins? My intent is yes for both. > 3. Should __halt_compiler() retain its current behavior in .phpc > files? My intent is yes. > > I welcome substantive critique. If the concept itself is unwanted, I > would rather know now than discover it during a vote. > > Thanks. > > Hendrik Mennen > Maintainer, PHPolygon > -- Med venlig hilsen Henrik Skov /HSK Consulting/ Blegdamsvej 128B, 4 DK-2100 Copenhagen O Tel.: +45 27 62 83 01 Email: henry.wood.dk@gmail.com --------------zU0vgBlEclqaMncE079zTnvs Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi internals !

I fail to see the upside ?
What does such a feature provide as an upside to users ?
Is it performance only ? The performance gain would be negible wouldn't it ?

/Henrik

On 27/05/2026 14.12, hmennen90@gmail.com wrote:
Hi internals,

I intend to submit an RFC introducing a new file extension for pure-code PHP source files (no leading <?php required) and would like to gather feedback before drafting.

Proposal in brief:

Files ending in .phpc would be parsed starting in ST_IN_SCRIPTING state. No <?php or ?> tags permitted inside such files. Existing .php files and their semantics are completely unchanged. This is purely additive and BC-clean.

Motivation:

PHP's mixed-mode default reflects its 1995 templating origins. Since PHP 7+, the language has evolved into a credible general-purpose tool: strict types, enums, readonly classes, property hooks, JIT compilation. I personally maintain PHPolygon, a CPU-bound 3D engine written in PHP – a use case where the templating heritage is pure ceremony. Other modern uses (CLI tooling, queue workers, code generators) share this pattern. A dedicated pure-code file format would be a small but meaningful acknowledgment that PHP-as-language is now a first-class use case alongside PHP-as-template.

Prior art and what's different:

I have read both rfc/source_files_without_opening_tag (Boutell, 2012, abandoned by author) and rfc/nophptags (Ohgaki, 2014, inactive). My proposal deliberately avoids what I believe were the two design choices that killed them:

- No new include syntax (Boutell's AS keyword). Extension-based detection only.
- No php.ini-based mode switch (Ohgaki's template_mode). No global config side effects.
- No security framing. The mode-switch overhead is parse-time only and OPcache/JIT eliminate it in practice; this proposal is about conceptual clarity and tooling, not performance or LFI mitigation.

Implementation:

I will write and maintain the implementation patch. Initial scope: extension registration in zend_compile_file, lexer state initialization, OPcache awareness, CLI support, and rejection of <?php/?> tokens inside .phpc files. I will also coordinate with Composer maintainers ahead of RFC submission to confirm autoload support.

Open questions for the list:

1. Is the .phpc extension acceptable as the disambiguator, or is there appetite for something else (e.g. shebang line, declare directive – both of which I think are worse, but I'd hear the case)?
2. Should #! shebang lines and UTF-8 BOM be permitted before the implicit scripting state begins? My intent is yes for both.
3. Should __halt_compiler() retain its current behavior in .phpc files? My intent is yes.

I welcome substantive critique. If the concept itself is unwanted, I would rather know now than discover it during a vote.

Thanks.

Hendrik Mennen
Maintainer, PHPolygon

--



Med venlig hilsen

Henrik Skov
HSK Consulting
Blegdamsvej 128B, 4
DK-2100 Copenhagen O
Tel.: +45 27 62 83 01
Email: henry.wood.dk@gmail.com
--------------zU0vgBlEclqaMncE079zTnvs--