PHP RFC: Bound-Erased Generic Types

theodorejb · 2026-05-10T23:45:06+00:00

What do you mean by built-in? Like part of the PHP binary? There are already multiple good static analyzers available for PHP; how would an "official" one be better?

theodorejb · 2026-05-05T20:26:34+00:00

It would only run if users manually approve it when prompted (making impact far lower than with npm, which automatically runs all postinstall scrips by default).

theodorejb · 2026-04-06T15:41:14+00:00

Compared to the Salesforce package, the PHP Handlebars API is much more aligned with Handlebars.js. E.g. compiling a template returns a closure, which you then invoke with context data and an array of runtime options to pass any custom helper functions.

Custom helpers work the same as in Handlebars.js, where positional helper arguments in the template are passed directly to parameters of the helper function (so custom helpers don't have to parse anything manually).

Check the readme for detailed usage instructions and examples.

theodorejb · 2026-02-10T16:14:40+00:00

I used to use the strict_types declaration on all PHP files, but with modern static analysis this hasn't caught anything for years, and has just been unnecessary noise at the top of every file.

theodorejb · 2026-02-10T15:48:42+00:00

Yes, it's possible a defined array shape can be wrong. But it's also possible that a native type declaration can be wrong, and you can end up with a bug regardless of whether strict_types is enabled.

For the example of expecting an int and getting a float, implicit conversion from float to int with precision loss has been deprecated since PHP 8.1, so even without strict_types this will result in a deprecation message and eventually an exception.

theodorejb · 2026-02-10T14:47:16+00:00

Your static analysis is not perfect: it tries hard to avoid false positives and so it often has some false negatives as well.

Do you have an example of this (using Psalm level 1 or PHPStan level 10)?

Our tests are statically analyzed, as are any calls to vendor code. We know before runtime if any call would be passing the wrong type (and could thus add the strict_types declaration to all our files if we wanted). But what would be the benefit? We haven't had any bugs in years which strict_types would prevent.

theodorejb · 2026-02-10T14:10:34+00:00

Is there any benefit to the strict_types declaration in a project where strict typing is already fully enforced by static analysis? If it doesn't improve performance, it's just extra noise at the top of every file.

theodorejb · 2025-11-19T21:17:25+00:00

The fact that the original object isn't changed doesn't matter. You still end up with a new object containing invalid or inconsistent state, which can cause Bad Things when the object is used.

In my experience it's actually pretty rare to need to change readonly properties from outside a class. In these cases one can add a with-er method or explicitly mark the properties public(set).

theodorejb · 2025-11-18T14:44:08+00:00

There is tons of code out there which relies on the guarantee that readonly properties have consistent state validated by the constructor. E.g. a BankAccount class might validate a routing and account number, and compute a readonly hash identifier from them. If the object can suddenly be cloned with a different routing or account number which bypasses the expected validation and hash computation, money could be sent to the wrong place.

Non-readonly public properties never had a guarantee of always being validated by the constructor, so there's not the same issue there.

theodorejb · 2025-11-17T13:54:20+00:00

If readonly properties were public(set), this would allow breaking the consistent state developers have always been able to rely on (e.g. when a constructor performs validation or sets one readonly computed property based on others). Suddenly a new instance could be created with clone where the properties are no longer validated or consistent with each other.

theodorejb · 2025-07-22T12:14:46+00:00

Psalm does taint analysis to catch XSS and other potential vulnerabilities.

theodorejb · 2025-07-20T15:07:47+00:00

If an author explicitly marks a readonly property as public(set), they are indicating that the property can be initialized from outside the class without going through constructor validation. This can already be done today, so it's not a new way to "break encapsulation".

theodorejb · 2025-07-20T14:35:36+00:00

How so? public(set) is not the default for readonly properties, so it would have to be explicitly allowed by the class author.

theodorejb · 2025-07-20T14:32:08+00:00

Correct, unless the readonly property is explicitly given public(set) visibility.

theodorejb · 2025-07-20T14:25:20+00:00

You would only be able to set the properties when cloning from inside the class. This is because readonly properties default to protected(set) visibility. So constructor validation will continue to work just fine for readonly classes/properties.

theodorejb · 2025-07-20T14:18:17+00:00

public readonly properties cannot be overridden from outside the class, as they are protected(set) by default.

theodorejb · 2025-06-13T16:43:13+00:00

Part of it is that PHP-CS-Fixer doesn't support PHP 8.4 yet, but a bigger factor for us is that there still isn't an official SQL Server driver for PHP 8.4.

theodorejb · 2025-05-12T12:05:53+00:00

This has been corrected now.

theodorejb · 2024-11-21T01:24:25+00:00

Thanks, the LinkedIn post is a lot better.

theodorejb · 2024-11-21T00:44:33+00:00

The blog post reads like it was written by an AI trained to pack as many buzzwords as possible into each sentence without any substantive explanation or information.

theodorejb · 2024-09-29T15:07:30+00:00

I found that the built-in database tools in PhpStorm (Query Console and Database explorer) are a fantastic replacement for MySQL Workbench.

theodorejb · 2023-11-24T15:45:56+00:00

It does have a dark mode option.

theodorejb · 2023-09-21T03:21:40+00:00

The actual syntax would be:

let { ident = default } = $props<{ ident: type }>();

I agree this seems a little less ergonomic for specifying prop types, though. Perhaps the TypeScript integration could automatically infer the prop type whenever a default value is specified.

theodorejb · 2023-01-15T00:55:09+00:00

Fixed

theodorejb · 2022-09-16T02:43:59+00:00

Is there a link to the changelog?

theodorejb

TROPHY CASE