juin
2008
Un article de doctorrock
J’ai téléchargé récemment un snap de PHP5.3, en lançant les tests PHPUnit, il y a eu des erreurs.
Ca fait longtemps que nous suivons le développement de PHP5.3 dans le cadre du développement du ZendFramework, car l’objectif est que celui-ci soit 100% compatible dès la sortie de PHP5.3 (2008).
Depuis cette version de snaps (je n’ai pas le numéro de version CVS exact), les méthodes __get(), __set(), __call(), __isset() et __unset() déclarées comme non publiques ou statiques, emmettent une fatal error à la compilation.
En gros : ce code fonctionne très bien sous PHP5.2, mais pas sous PHP5.3 :
class uneClasse
{
protected function __get($prop) { }
public static function __set($prop,$val) { }
}
Au niveau du static, je suis d’accord, elles ne fonctionnaient de toute façon pas avant, en PHP5.2, statiquement, mais elles ne revoyaient aucune erreur. Maintenant elles en renvoient une, c’est une bonne chose ( PHP5.3 introduit aussi une nouvelle méthode magique __callstatic() dont le nom est explicite )
Concernant la visibilité, c’est déja une autre affaire. Quelques classes du ZendFramework utilisent des __get() et __set() non publiques (c’est le cas de Zend_Session_Namespace, ou encore de Zend_Config notamment).
La réécriture de tels algorithmes, pour passer cette nouvelle « fonctionnalité » peut s’avérer longue et difficile, si vous êtes dans ce cas là, commencez tout de suite à y réfléchir.
Pourquoi avoir bloqué la visibilité de ces méthodes ? Pourquoi ne pouvons-nous plus les utiliser en interne dans une classe (non publiques) ?
Il doit y avoir une bonne raison, j’ai vaguement fouillé les mailing-lists (très vaguement même), sans trouver, quelqu’un a-t-il le post original ? 
6 Commentaires + 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
Cool, c’est un gars avec qui je bosse sur ZF aussi, il est responsable des tests, de Zend_Session, d’une partie de MVC, et de bien d’autres choses encore
Ralph Schindler s’étonne aussi de ce comportement, la discussion est ici : http://marc.info/?l=php-internals&m=121495299306756&w=2
Bien vu Yogui en effet, très intéressant
ben le coup du constructeur qu’on peut mettre en privé pour le singleton c’est comme en java effectivement.
et on dirait bien que tu as trouvé le post à l’origine de ces erreurs qui remontent, chapeau
Salut
Les méthodes magiques ne sont pas définies par défaut, il ne s’agit donc pas d’une surcharge. C’est un peu le même principe pour __construct, et c’est d’ailleurs ce qui nous permet de mettre en place le design pattern Singleton (utilisé par ZF, d’ailleurs).
J’ai trouvé cette RFC, mais elle suggère plutôt un élargissement de protected que sa restriction, et il n’est pas question des méthodes magiques : http://wiki.php.net/rfc/protectedlookup
Cela dit, voici un message de Marcus Boerger (helly) :
salut,
normalement on ne peut pas restreindre la visibilité d’une méthode quand on la redéfinit non ?
en même temps dans la doc php, ils parlent de surcharge et pas de redéfinition …
ca doit donc dépendre de comment elles sont définies dans le parent si jamais y en a un car c’est des méthodes « magiques » c’est vraiment particulier.
fin bon si tu as une réponse, ça m’interresse