novembre
2007
Un article de doctorrock
Le code d’erreur E_STRICT n’est actuellement pas inclu dans E_ALL.
Il le sera en PHP5.3 et PHP6, mais il sera sindé en 2.
E_STRICT repèrera toutes les erreurs de conception dans le code, et devrait générer une erreur de type E_ERROR, soit fatale (arrêt immédiat du script)
En revanche, le nouveau E_DEPRECIATED lui, génèrera des E_NOTICE, au sujet de comportements dépérciés et amenés à disparaitre.
Voici un concept interessant, regardez :
class a
{
function test($t = 'titi')
{
return $t;
}
}
class mytest extends a
{
function test($t)
{
return $t;
}
}
En PHP5 (<5.3), ceci génère une erreur de type E_STRICT : Strict Standards: Declaration of mytest::test() should be compatible with that of a::test() in **** on line 16
C’est tout à fait normal, car de manière conceptuelle, un héritage ne doit pas casser un lien entre parent – enfant. L’enfant doit faire au moins ce que fait son père, et plus si le coeur lui en dit.
Dans cet exemple, l’enfant ‘mytest’ court-circuite son père ‘a’, car il rend le paramètre de la méthode test obligatoire, alors qu’il était facultatif. C’est un défaut de conception logicielle. C’est comme si un enfant s’acapare une propriété de classe : un parent la définit en protected, l’enfant, quelqu’il soit, ne peut pas la définir en private, car alors on ne pourrait plus l’hériter.
La nouveauté qui risque de ne pas ravir tout le monde, est que PHP5.3 et PHP6 change ce rapport et génèrent, actuellement une E_ERROR. Et que ceci est compris dans E_ALL.
Ainsi, le code d’exemple ci dessus plante lamentablement avec un fatal error, sous PHP supérieur à 5.3, alors que sous PHP inférieur à 5.3, si E_STRICT n’est pas activé, le code fonctionne à merveille.
C’est la même chose avec les interfaces, sauf que là, c’est la fatal error, quelque soit la version de PHP utilisée.
Notez que seul le constructeur admet un héritage ‘bancal’, ce qui est logique : par exemple en java, le polymorphisme est meilleur, car une classe peut avoir une infinité de constructeur.
En PHP, ca n’est pas le cas, mais pour assurer un polymorphisme correct, on admet qu’un constructeur enfant puisse redéfiir son père de manière plus restrictive.
Conclusions (que je repète systématiquement à tous mes stagiaires) : développez tout le temps avec un rapport d’erreur égal à E_ALL | E_STRICT. C’est tellement plus logique de faire propre ^^
1 Commentaire + Ajouter un commentaire
Commentaires récents
Archives
- novembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
- décembre 2008
- novembre 2008
- octobre 2008
- septembre 2008
- août 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
- mars 2007
- février 2007
Merci Julien, je l’avais oublié celui-là