> Erreichen will man, dass ein typischerweise in IDEs eignebauter Parser anspringt und aus den Kommentaren Code-Dokumentation macht. Die ist dann im ganzen Projekt verfügbar und zeigt bei der Eingabe z.B. von Funktionsnamen die definierten Parameter und Rückgabewerte. Inzwischen haben phpdoc-Kommentare häufig sogar eine eigene Semantik, die über die bloße Dokumentation weit hinausgeht. Beispiele dafür sind Typchecker, Object-relational-Mapper und Service-Locator-Pattern, die sich als Dependency-Injection missverstehen. Der Missbrauch der Kommentare wurde aus der Not heraus geboren, weil PHP kaum Mittel für Metaprogrammierung bietet.

> Erreichen will man, dass ein typischerweise in IDEs eignebauter Parser anspringt und aus den Kommentaren Code-Dokumentation macht. Die ist dann im ganzen Projekt verfügbar und zeigt bei der Eingabe z.B. von Funktionsnamen die definierten Parameter und Rückgabewerte. Inzwischen haben phpdoc-Kommentare häufig sogar eine eigene Semantik, die über die bloße Dokumentation weit hinausgeht. Beispiele dafür sind Typchecker, Object-relational-Mapper und gruselige Dependency-Injection-Services[^1]. Der Missbrauch der Kommentare wurde aus der Not heraus geboren, weil PHP kaum Mittel für Metaprogrammierung bietet. [^1]: Gruselig deshalb, weil dann zumeist die Abhängigkeiten aus einem globalen Objekt-Pool geladen werden. Die Verantwortung darüber die richtige Abhängigkeit aus dem Pool zu fischen verleibt allerdings beim abhängigen Objekt, dem Client. Das ist also so ziemlich genau das Gegenteil von Dependency-Injection im Sinne von Inversion-of-Control. Das ist mir in ziemlich übler Erinnerung geblieben, als ich vergangenes Jahr für drei Monate an einem Java-Projekt gearbeitet habe. Die Java-Community setzt exzessiv auf dieses Pattern und nennt es fälschlicherweise Dependecy-Injection. Bei Typo3 hat man das dann übernommen.