The plugin docs say new, not getClass

[mastacontrola]

The published-docs half of FOGProject/fogproject#1710 and FOGProject/fog-plugins#38, which retired the literal getClass('X') in favour of a plain new (fogproject ADR 0043).

These two files are the published copies of developer docs that currently tell plugin authors to do the opposite:

• docs/development/plugin-development.md — the "one place a bare name still bites" section, the establishSession() example, and the checklist bullet that reads "prefer self::getClass('HelloWorld') … over new".
• docs/development/storage-node-selection-hooks.md — the pickNode() example a hook author is meant to paste.

Why it is not just a spelling preference

getClass() is declared @return object|mixed, so nothing can check what you then do with the result and no editor can follow it to a definition. Converting core's 459 literal sites surfaced 90 PHPStan errors against a baseline that reported zero — every one a pre-existing annotation that had drifted from its body (@return void on a method ending return $queries;; @return object on methods that return false;, which made every if (!$x->destroy()) guard in the tree read as dead code).

It was never a substitution seam either: qualify() consults core's map before the plugins', which is what stops a plugin answering a core name.

Plugins spell it fully qualified rather than importing, because fog-plugins' own tests/core-references-are-qualified.test.php refuses a bare core name — that tree is fetched on its own and cannot assume a fogproject checkout is nearby.

getClass() with a variable is unchanged and still documented. That is the one shape new cannot express, and it is what the function is for now.

Translations

English only. scripts/translate.mjs regenerates the six translations from this source, so hand-editing translations/*/development/*.md would be overwritten on the next run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01684dJC9hw1jY4KjzV81BLC