La RFC Static classes partait du constat qu’il est aujourd’hui possible de créer des classes avec propriétés et méthodes statiques uniquement, mais qu’il est impossible de les définir comme non instanciables sans passer par un constructeur privé, ce qui rend notamment ces classes non testable.

Le but de cette RFC était d’ajouter un mot clef static au niveau de la classe afin de définir l’intégralité de son comportement comme tel :

static class Environment
{
    private $rootDirectory = '/var/www/project';
    public function getRootDirectory()
    {
        return self::$rootDirectory;
    }
}

Notons toutefois qu’aujourd’hui, un tel comportement est presque possible en utilisant une classe abstraite :

abstract class Environment
{
    static private $rootDirectory = '/var/www/project';
    static public function getRootDirectory()
    {
        return self::$rootDirectory;
    }
}

Néanmoins, cette syntaxe présente plusieurs limites que la RFC souhaitait couvrir :

  • il est possible d’oublier un mot-clef static<br />
  • la classe peut être étendue et donc instanciée par le biais d’une classe fille, la rendant non statique : il faudrait y ajouter le mot clef final.

C’est pour cette raison que la RFC fut lancée sous le nom de Abstract Final class. Le but premier était de donner la possibilité de rendre une classe abstraite finale.

Le principe fut rejeté car une classe abstraite a pour but même d’être étendue alors qu’une classe finale ne peut pas l’être !
C’est pour cette raison qu’après moult échanges en interne, la RFC fut proposée une nouvelle fois sous son nouveau nom, afin d’ajouter un nouveau mot clef pour lever toute incompréhension.

S’il est vrai que définir une classe comme statique dès sa déclaration à l’avantage indéniable de clarifier son rôle, il est toutefois ressorti de nos échanges qu’il semblerait que la plupart des cas d’utilisation étaient des collections de fonctions, parfois appelées helpers. La majorité fut contre cette demande, principalement car les classes statiques ne sont pas reconnues comme une pratique à encourager. Nous avons donc posté en ce sens sur internals@.

La RFC a été rejetée par 12 voix contre 5. Toutefois,  même si cette proposition voulait couvrir un périmètre plus large, le chargement automatique des fonctions est un sujet qui est ressorti plusieurs fois au cours de nos discussions. Un souhait visiblement partagé par de nombreux développeurs.