Discussion :

[kaymak]

Là précisèment je ne peut te donner le message d'erreur car je suis repassé sur la 5.2.9. Mais j'ai un exemple en tête.

fron scratch :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class logger extends ArrayObject{
public function append( $message, $categorie, $niveau ){
}
}

Normalement avec cet exemple, et en te positionnant sur e_strict, php devrais emettre un message concernant la signature de la méthode logger::append qui n'est plus compatible avec ArrayObject::append.

donc bof, j'ai pas envie de mettre ces arguments en optionnel cela me ferait du job que php peut déjà faire.

m'enfin je vérifierais tout de même tout à l'heure que l'exemple est ok.

[berceker united]

Là précisèment je ne peut te donner le message d'erreur car je suis repassé sur la 5.2.9. Mais j'ai un exemple en tête.

fron scratch :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class logger extends ArrayObject{
public function append( $message, $categorie, $niveau ){
}
}

Normalement avec cet exemple, et en te positionnant sur e_strict, php devrais emettre un message concernant la signature de la méthode logger::append qui n'est plus compatible avec ArrayObject::append.

donc bof, j'ai pas envie de mettre ces arguments en optionnel cela me ferait du job que php peut déjà faire.

m'enfin je vérifierais tout de même tout à l'heure que l'exemple est ok.

Là, je dirais que ça reste discutable. Pour moi il y a pas de raison que ça puisse péter une erreur, vu que tu souhaites surcharger une méthode d'une classe parente. Par contre, il n'est toujours pas possible de surcharger une méthode d'une même classe en changeant sa signature et je pense que c'est ça qui fait qu'il y a conflit d'erreur.
Peut être que c'est une erreur et tu peux éventuellement ouvrir un ticket sur ce point. Pour moi, il y a pas de raison que cela change à moins que cela était prévus.

[Yogui]

Salut

Pour info, la surcharge de méthode d'une classe parente est soumise à certaines contraintes (bonnes pratiques POO) :

• même nombre d'arguments obligatoires
• même visibilité (public/protected/private)

C'est simplement l'implémentation POO par PHP qui le préconise. La réflexion est que si on change ces aspects d'une méthode, alors le polymorphisme n'est plus la même. Si j'ai une classe A et une classe B qui en dérive, je dois pouvois appeler les méthodes de B de la même manière que celles de A puisque ce sont des objets compatibles : si vous changez la visibilité de la méthode ou le nombre d'arguments obligatoires, alors ce n'est plus possible et vous cassez toute la conception OO de votre application.

[berceker united]

Salut

Pour info, la surcharge de méthode d'une classe parente est soumise à certaines contraintes (bonnes pratiques POO) :

• même nombre d'arguments obligatoires
• même visibilité (public/protected/private)

C'est simplement l'implémentation POO par PHP qui le préconise. La réflexion est que si on change ces aspects d'une méthode, alors le polymorphisme n'est plus la même. Si j'ai une classe A et une classe B qui en dérive, je dois pouvois appeler les méthodes de B de la même manière que celles de A puisque ce sont des objets compatibles : si vous changez la visibilité de la méthode ou le nombre d'arguments obligatoires, alors ce n'est plus possible et vous cassez toute la conception OO de votre application.

Je suis d'accord avec toi. Par contre, je m'étonne qu'avant cela ait pu fonctionner avant comme il le décrit.

[kaymak]

Je sais bien yogui.... Mais en php5.2 sa ne le faisait pas et sa m'arrangeait bien.
La je serais obliger de modifier le design en implémentant countable et iterator pour garder le même appel.... si ce n'est plus.

[berceker united]

Je sais bien yogui.... Mais en php5.2 sa ne le faisait pas et sa m'arrangeait bien.
La je serais obliger de modifier le design en implémentant countable et iterator pour garder le même appel.... si ce n'est plus.

Donc cela signifie que tu as mal monté ton affaire .
Ce qui m'étonne pourquoi cela ait été changé maintenant ?

[Yogui]

Cela n'a pas vraiment changé, il me semble qu'avec PHP 5.2 c'était déjà inclus dans le niveau E_STRICT. Peut-être que PHP 5.3 a simplement rendu ce niveau d'erreurs plus visible, je n'ai pas vérifié. Quelqu'un a-t-il davantage d'informations ?

[Floréal]

Bonjour,
Je me pose des questions quant à l'utilisation de la fonction __autoload() en php 5.3.
En effet l'introduction des namespace sucite ma curiosité, je vais illustrer cela par quelques exemples:
partant de ces deux scripts:

Class.class.php:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<?php
class Classe {
  //...
};

ns/Class.class.php:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?php
namsepace \ns;
class Classe {
  //...
};

ns/Class2.class.php:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<?php
namsepace \ns;
class Classe2 {
  //...
};

cas 1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$objet1 = new \Classe();
$objet2 = new \ns\Classe();

cas 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
use \ns;
$objet1 = new Classe2();

Comment doit-on définir la fonction __autoload() dans le premier cas?
Est-ce que les namespaces préfixés sont passés en paramètre de la fonction __autoload()?
Existe-t'il, pour le second cas un équivalent de __autoload() pour les namespaces à redéfinir (appelée lors de l'utilisation d'un use, par exemple, pour savoir si la classe)?

En fait je pensais à un truc dans ce genre là était possible (en s'appuyant sur l'exemple que j'ai donné un peu plus haut):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
function __autouse($ns) {
  global $__used_ns_dirs;
  if (!isset($__ns_dirs)) {
    $__used_ns_dirs = array()
  }
  $__used_ns_dirs[] = $ns;
}
 
function __autoload($class_name) {
  global $__used_ns_dirs;
  $search_dir = isset($__used_ns_dirs) ? $__used_ns_dirs : array();
  foreach ($search_dir) {
    // ajout de la classe avec les verifications necessaires (INCLUDE_PATH, etc.) en tennat compte des namepsace.
  }
}

[metagoto]

Quand php appelle les __autoload, le nom de la classe qui est passé en paramètre est un nom complètement qualifié (cependant, le premier '\' n'est jamais passé).
Exemple, si le namespace courant est machin\truc et que tu fais $a = new A; alors php va regarder si machin\truc\A existe. S'il ne trouve pas la classe, il appelle l'autoload avec machin\truc\A comme nom de classe.
Si machin était un alias pour, disons, autre\bidule, alors autoload recevra autre\bidule\machin\truc\A comme nom de classe.

C'est ce genre d'autoloading que j'utilise:
http://www.developpez.net/forums/d76...ng-namespaces/
Plusieurs autoloaders basés sur ce principe sont registrés auprès de spl_autoload_register(). En fait, une registration par racine de namespace:

Genre si j'ai un namespace framework (et possiblement des sous ramifications framework\blah\bleh..), j'aurais un autoloader pour framework, qui est un composant du framework.

Si j'ai un autre namespace myself\machin\truc, j'enregistre un autoloader similaire qui gère uniquement myself et ses descendants.

Je n'ai rien dans l'include_path parceque j'en n'ai pas besoins. Il y a un mapping directe entre les branches des namespaces et les répertoires du filesys. Je pense que c'est un bon compromis en terme de performance (aucun lookups) et de facilité d'utilisation.

[Floréal]

Ah oui, c'est vraiment pas bête. Je n'avais pas envisagé les choses sous cet angle là. Ce que tu propose est intéressant et me plait beaucoup.

[gene69]

La question est "que pensez vous de php5.3"?

ma réponse est que du bien !

• d'abord je me moque des histoires de syntaxes compliquées, logiques ou pas (quoi que je fasse des fonctions anonymes depuis peu)
• parce que ya plein de fonction qui n'étais pas native windows et qui le sont devenue
• parce que j'ai eu 0 problème pour faire passer des scripts d'un moteur php 4.3 à 5.3.1, hormis la mode qui veut qu'on ne fait plus de magic quote ni de balise brève.
• parce que j'ai trouver des trucs sympa comme __DIR__ et pour moi qui me limite a des syntaxes triviale, c'est génial.

[guk92]

Le PHP est un très bon langage informatique, il ne lui manque plus que la gestion de l'UNICODE, d'intégrer des API standards sans passer par des framework tierce (ex: génération de document PDF), et d'être un peu plus rapide à l'exécution.