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
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:
- 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)?- Should #! shebang lines and UTF-8 BOM be permitted before the
implicit scripting state begins? My intent is yes for both.- 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