11 Janvier 2026 - Refactoring Architectural

Du refactoring? Déjà?! il s'agit des fondations du framework, je demande à Claude de passer en revue l'implémentation avec un "oeil" de DEV.
Et effectivement des "faiblesses" sont à corriger:

du code dupliqué!
has() n'est pas 100% conforme au PSR-11
nouveau besoin: un path_resolver
nouveau besoin: un Parameter_resolver_interface qui permet de découpler la Config du Container, ce qui n'était pas cohérent pour un IoC!
suppression de code "mort", approche YAGNI

Le code dupliqué et mort, à fixer en premier, pour le reste voyons rapidement ci-après.

has()

Problème identifié: Pour être conforme PSR-11. has() doit retourner TRUE uniquement pour les services explicitement enregistrés (les bindings, les instances déjà créées, ou les alias). get() tentait l'auto-wiring même si has() retournait FALSE.

Le Path_resolver

Une vielle habitude que cette variable globale (ROOT) partout, ce qui est un non sens avec un système IoC! La solution passer par une classe Path_resolver ec qui rend le code injectable et testable.

Le Parameter_resolver_interface

Cela permet de découpler Container de Config (principe SOLID : Dependency Inversion).

Autant pour la conception et l'analyse du fait de la difficulté à transmette 100% du contexte, Claude montre certaines limites, voir parfois hallucine. Autant pour ce qui est de la logique pure, écriture de tests, review de code c'est un outils efficient.
C'est un gain de temps énorme. Bien utilisé, c'est un outils indispensable!