Mise à jour le 13/11/2021
PHP RFC: Default constructors

PHP RFC: Default constructors

1. Présentation de la RFC

Date: 2014-11-05
URL : https://wiki.php.net/rfc/default_ctor
Auteur: Stas Malyshev

Cette RFC a été refusée car elle n'a pas eu assez de votes POUR alors qu'en majorité absolue, elle aurait pu passer (27 POUR VS 20 CONTRE).

L'idée derrière cette RFC est assez simple, on permet à une classe fille d'utiliser même s'il n'existe pas le constructeur de la classe mère.

Selon l'auteur, on pourrait toujours faire un parent::__construct(); dans le constructeur de la classe fille sans trop se soucier de ce que fait exactement la classe mère. Cela éviterait aussi de devoir modifier toutes les classes filles si jamais leur classe mère avait d'un coup un constructeur.

Pourquoi ce n'est pas grave si cette RFC ne passe pas ?
Alors, il me semble tout à fait raisonnable de penser que le role du développeur est non seulement d'être curieux sur les classes dont hériteraient les siennes mais en plus d'être responsable en les utilisant de la bonne manière.

La classe mère est modifiée ? Qu'à cela ne tienne : oui il faut peut-être rééditer toutes les classes filles. Oui, cela peut tout à fait être rébarbatif, mais le seul domaine où le développeur ne doit pas être paresseux est justement celui de la programmation.
Créer un constructeur par défaut vide et laisser les développeurs l'utiliser dans leurs classes filles "au cas-où", non seulement ce n'est pas très rigoureux comme façon de faire, mais en plus, rien n'indique que le constructeur, s'il venait à être créé dans la classe mère n'aurait aucun paramètre, donc, il serait fort probable que dans beaucoup de cas, il faille de toute façon revenir sur le constructeur des classes filles.

2. Alors que faire pour pallier à ceci ?

Et bien, on peut tout à fait créer une classe intermédiaire dont étendrait les classes filles qui possèderaient un constructeur qui héritera si besoin du constructeur de la classe grand-mère. Cela ne permet pas de répondre à un constructeur qui aurait plusieurs paramètres, mais cela permet en tout cas de répondre au besoin de cette RFC.

2.1 Proposition d'implémentation

Nous avons ici quatre classes, la classe GrandPa, celle dont va hériter la classe Dad, elle-même dont héritent les classes Daughter et Son.
La classe Dad joue ici un rôle de tampon entre la classe GrandPa et les deux autres, on peut lui créer un constructeur vide "au cas-où" qui héritera si besoin du constructeur de la classe GrandPa si jamais celui-ci venait à être créé dans le futur.

<?php

class GrandPa
{
    
}

class Dad extends GrandPa
{
    public function __construct()
    {
        
    }
}

class Son extends Dad
{
    public function __construct()
    {
        parent::__construct();
    }
}

class Daughter extends Dad
{
    public function __construct()
    {
        parent::__construct();
    }
}

Ici encore, c'est une idée que je ne cautionne pas dans la mesure où c'est du code qui ne sert à rien au moment où il est fait, autant se retrousser les manches au bon moment plutôt que de prévoir d'innombrabres probables situations.

3. Conclusion

C'est plutôt une bonne chose que cette RFC ne soit pas validée car la création de constructeurs fictifs aurait surement créé plus d'effets de bord qu'autre chose, car si jamais la classe mère était mise à jour sans même que le développeur s'en aperçoive, c'est à ce moment là qu'il perdrait la maitrise de son code. Développer sur de l'implicite ne me semble pas être une bonne chose.