Re: [PHP-DEV] [Concept] declare(strict_identifiers=1)

در تاریخ پنجشنبه ۲۷ اوت ۲۰۲۶، ۰۱:۲۳ Derick Rethans <[email protected]> نوشت:

> On 26 August 2026 22:24:06 BST, Larry Garfield <[email protected]>
> wrote:
> >On Wed, Aug 26, 2026, at 2:42 PM, [email protected] wrote:
> >
> >> The survey answers a different question: if a maintainer adds the
> declare
> >> to a file they already have, does it still compile? That is adoption
> >> friction, not breakage. It is also a calibration check -- a rule that
> >> rejected a lot of legitimate existing code would be the wrong rule, and
> I
> >> wanted to know that before proposing it rather than after.
> >>
> >>  > Do I understand it correctly that by adding that declare to 168604
> you
> >>  > would uncover a single risky identifier? Not that convincing...
> >>
> >> That number is the cost, not the benefit, and I should have separated
> the
> >> two more clearly.
> >>
> >> The single Packagist finding is what would stop compiling: symfony/cache
> >> declares a class whose entire name is the single byte 0xA9. That is the
> >> whole measured adoption cost across the 250 most-installed packages.
> >
> >If this is so rarely seen in the wild (something that should be verified
> with more than 250 packages), why make it an option?  Just plan that PHP 9
> will enforce UTF-8-or-GTFO rules on identifiers, Symfony updates one
> oddball class, and we move on with life.  99.99% of developers won't notice
> anything happened.
> >
> >--Larry Garfield
>
> Is it important enough to have this memory footprint added to each PHP
> process though?
>
> > About 13.7 KiB of generated tables
>
> cheers
> Derick



------------

Hi Derick,

Good point. The ~13.7 KiB footprint comes from the static lookup tables
generated for fast classification.

A couple of aspects regarding how this is handled / can be optimized:
1. Shared Memory (`.rodata`): Since these tables are declared as `static
const`, in standard multi-process setups (e.g. PHP-FPM), they reside in
read-only memory pages shared across processes rather than allocating
per-process heap memory.
2. Compacting / Range Encoding: We can definitely look into compressing the
lookup tables (e.g., using run-length/interval encoding or two-stage lookup
tables) to bring the table size well under a few kilobytes if the raw table
footprint is a concern.

I’m happy to explore compressing the tables or benchmarking the memory
impact across different setups to ensure the footprint remains negligible.

Best regards,
Sepehr


>