2010-11-03 3 views
4

J'ai créé un modèle Zend Framework en étendant Zend_Db_Table_Absract comme suit (exemple simplifié):Pourquoi est-ce que j'obtiens ce message sur les normes strictes?

class Foos extends Zend_Db_Table_Abstract 
{ 
    protected $_schema = 'Foo'; 
    protected $_name = 'Foos'; 
    protected $_primary = 'id'; 
    protected $_sequence = true; 

    public function insert($data) { 
     $db = $this->getAdapter(); 
     $record = array('field1' => $data['field1'], 
         'field2' => $data['field2'], 
         ... 
       ); 
     return parent::insert($record); 
    } 
} 

ci-dessus insère correctement un enregistrement. Le problème est, je continue à obtenir l'avis suivant:

Strict Standards: Declaration of Foos::insert() should be compatible with that of Zend_Db_Table_Abstract::insert() in /x/x/x/Foo.php on line XX 

Pour autant que je peux dire d'avoir lu la documentation et l'API à plusieurs reprises, la façon dont je le fais est correct. Je suis conscient que je peux désactiver E_STRICT mais je préfère savoir pourquoi je reçois l'avis ci-dessus. Des idées? (PHP 5.3, Zend Framework 1.10)

+0

Juste vérifié dans la source: c'est la fonction publique insert (array $ data) ' – Mchl

+1

Merci à tous pour vos réponses. – karim79

Répondre

12

Mchl est la plupart du temps correct, mais l'erreur que vous obtenez est le paramètre qui ne correspond pas exactement à savoir:

public function insert($data) { 

devrait être:

public function insert(array $data) { 

Notez le type array spécificateur avant $data, le mélange que vous voyez est le type de retour, le type d'argument est array.

+0

Spot sur, qui l'a résolu. Merci Viper! – karim79

+1

Exactement. Voir la ligne 1022 du [code source] (http://framework.zend.com/svn/framework/standard/branches/release-1.9/library/Zend/Db/Table/Abstract.php). – lonesomeday

0

Parce que votre méthode Foos :: insert() a une signature différente (liste d'arguments, modificateur d'accès) de Zend_Db_Table_Abstract :: insert(). Selon des règles strictes, les méthodes de la classe enfant qui remplacent les méthodes de la classe parent doivent avoir la même signature.

[modifier]

Au moins c'est ce que cela signifie généralement parce qu'en regardant Zend_Db_Table_Abstract :: insérer la documentation(), je ne vois rien d'autre ...

[modifier]

Archivez Zend_Db_Table_Abstract :: insert() s'il existe un indice de type pour l'argument $ data. Il est peut-être public function insert(array $data) {...

+0

Merci pour la réponse. Je ne vois pas la différence entre les deux signatures, les documents de l'API disent 'mixed insert ($ data)' qui correspond exactement à la signature de ma classe exemple - '$ data' étant un tableau associatif (paire clé/valeur) comme le l'exemple démontre. – karim79

2

il doit être public function insert(array $data) (notez le typehint tableau avant que les données de $)

1

L'erreur est lui-même parce que vous avez E_STRICT ensemble dans error_reporting ou error_reporting ini directive ...

En fait, ce qu'il dit est que ce n'est pas une bonne pratique de changer la "signature" d'une fonction par l'héritage. Un exemple:

class ParentClass { 
    public function doFoo() {} 
} 

class ChildClass extends ParentClass { 
    public function doFoo($bar) {} 
} 

Cela générerait cette erreur car les signatures parent et enfant ne correspondent pas. Maintenant, la signature est ce à quoi il ressemble à l'analyseur, donc:

public function doFoo($bar) {} 
public function doFoo($baz) {} 

Les deux signatures sont identiques. Les noms de variables n'ont pas besoin d'être identiques, mais le nombre de variables, leur ordre, leurs indicateurs de type et leurs valeurs par défaut doivent être identiques.

public function doFoo(array $bar, ParentClass $somethign, $biz = 'no') {} 
public function doFoo(array $baz, ParentClass $parent, $buz = 'no') {} 

Ils correspondent aussi bien, mais ceux-ci ne le font pas:

public function doFoo(array $baz, ParentClass $parent, $buz = 'no') {} 
public function doFoo(array $baz, ChildClass $parent, $buz = 'no') {} 

Ce n'est pas nécessairement « mauvais » à faire (cadres et les développeurs font tout le temps). En ce moment, le langage le supporte bien. La raison de l'erreur E_STRICT est que dans le futur la langue peut ne pas le supporter. Donc ça "t'avertit" que ça peut être une mauvaise idée d'utiliser ton design comme ça ...

+0

Merci pour l'explication ircmaxell :) – karim79

Questions connexes