Index: phpdoc/fr/appendices/migration4.xml diff -u phpdoc/fr/appendices/migration4.xml:1.5 phpdoc/fr/appendices/migration4.xml:1.6 --- phpdoc/fr/appendices/migration4.xml:1.5 Mon Aug 6 08:14:44 2001 +++ phpdoc/fr/appendices/migration4.xml Fri Aug 10 09:20:50 2001 @@ -1 +1,308 @@ - Migration de PHP 3.0 à PHP 4.0 Ce qui a changé en PHP 4.0 PHP 4.0 et le moteur Zend ont significativement amélioré les performances et les possibilités de PHP, tout en assurant une compatibilité ascendante maximale. Le maximum de codes existants sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront prêts sans modifications, mais il est bon que vous connaissiez les quelques différences, et que vous testiez vos applications avant d'effecteur le changement de cadre de production. Les indications suivantes vous mettront sur la voie. Comportement de l'analyseur L'analyse et l'éxecution sont désormais deux étapes complètement dissociées, et l'éxécution intervient lorsque le code, ainsi que tous ses inclusions et pré-requis, ont été complètement analysés et validés. Une des nouvelles conditions introduites est que les fichiers inclus et requis (include et require) doivent être syntaxiquement complets. Vous ne pouvez plus répartir différents cas de votre code dans plusieurs fichiers. Vous ne pouvez plus commencer une boucle for ou while, une condition if ou un cas switch dans un fichier, et finir la boucle ou placer les cas else, endif, case ou break dans un autre fichier. Il est toujours valable d'inclure du code supplémentaire depuis une boucle ou dans une condition, mais les accolades de bloc {...}, et les éléments de la boucle doivent être dans le même fichier ou chaîne évaluée avec eval. Cela ne devrait pas perturber trop de monde, car étaler son code de cette façon est plutôt un style à éviter. Une autre nouveauté est qu'il est plus possible de faire retourner une valeur avec un fichier requis (require) (mais c'est plutôt rare en PHP 3.0). Retourner une valeur avec un fichier inclus (include) est toujours possible. Rapport d'erreur Changement de configuration Avec PHP 3.0, le niveau de rapport d'erreur était obtenu en ajoutant les constantes numériques de chaque niveau de rapport. Généralement, on utilisait 15 pour afficher toutes les erreurs, et 7 pour afficher toutes les erreurs hormis les alertes simples. PHP 4.0 dispose d'un nombre significativement plus grand de niveaux de rapport d'erreur, et l'analyseur comprend désormais les constantes, lors des modifications. Le niveau de rapport d'erreur doit désormais être explicitement configuré en supprimant les niveaux dont vous ne voulez pas du niveau maximal, grâce à la fonction de OU exclusif. Ça a l'air compliqué? Supposons que vous souhaitiez afficher toutes les erreurs, hormis les alertes de style, qui sont repérées par la constante : E_NOTICE. Il suffit d'ajouter la valeur suivante dans le fichier php.ini: error_reporting = E_ALL & ~ ( E_NOTICE ). Si vous voulez supprimer en plus les alertes, vous pouvez ajouter la constante appropriée, en la combinant avec l'opérateur OU logique '|': error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING ). L'utilisation des vieilles valeurs de 7 et 15 est une très mauvaise idée, car elles ne prennent pas en compte les nouvelles classes d'erreurs, y compris certaines erreurs d'analyse. Cela peut conduire à de très étranges résultats, où le script n'affiche plus rien, malgré une erreur d'analyse. Cela a conduit à un grand nombre de rapport d'erreur dans le passé, alors que les programmeurs n'étaient tout simplement pas capables de repérer l'accolade manquante, car l'analyseur avait la consigne de cacher ces erreurs. Vérifier votre niveau d'erreur doit être le premier réflexe lorsque vos scripts meurent silencieusement. Le moteur Zend est considéré actuellement comme suffisamment mature pour ne plus causer ce genre de problème aujourd'hui. Nouveaux messages d'erreurs Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui doivent être considérées comme un très mauvais style, même s'il effectue bien la tâche qui lui est affectée, car ils ne sont pas robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans des situations où PHP 3.0 restera coi. La solution de facilité consiste à supprimer les messages de niveau E_NOTICE, mais c'est une meilleure idée de corriger le code à la place. Le cas le plus courant qui génèrera des messages d'alertes est l'utilisation de constantes sans guillemets comme index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les interpréter littéralement comme des chaînes, si aucune constante n'est définie à la place. Mais si jamais une telle constante est définie dans une autre partie du code, cela risque de produire des résultats étonnants. Cela peut devenir un trou de sécurité si un pirate arrive à redéfinir les constantes de telle manière que le script lui donne accès à un niveau de droits supérieur. PHP 4.0 vous signalera tout oubli de guillemets comme par exemple dans : $HTTP_SERVER_VARS[REQUEST_METHOD]. Modifier ce code en $HTTP_SERVER_VARS['REQUEST_METHOD'] rendra l'analyseur heureux, et améliorera grandement votre style et la sécurité du code. PHP 4.0 vous signalera les variables ou les éléments de tableaux non initialisés. Initialiseur Les variables statiques et les membres de classes n'acceptent plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait aussi les expressions. Cela est dû, encore une fois, à la séparation de l'analyse et de l'exécution : aucun code ne peut être exécuté tant que l'analyse n'est pas terminée. Pour les classes, il vaut mieux initialiser les membres dans le constructeur. Pour les variables statiques, une valeur fixe et simple est la seule chose qui viennent à l'esprit. <literal>empty("0")</literal> L'évolution la plus polémique est celle de empty. Une chaîne contenant seulement le caractère '0' (zéro) est maintenant considérée comme vide, alors qu'elle ne l'était pas en PHP 3.0. Ce nouveau comportement prend tout son sens dans les applications web, puisque tous les résultats de champs de type input sont de type chaîne de caractères, même si un nombre est demandé, et ce, grâce aux capacités de conversion automatique de PHP. D'un autre côté, cela peut casser votre code d'une manière très subtile, menant droit au comportement erratique, difficilement repérable si vous ne savez pas ce qui vous attend. Fonctions manquantes Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalités fonctions et extensions, vous vous rencontrer des fonctions PHP 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu être portées en PHP 4.0, maintenant que l'analyse et l'éxécution ont été séparées. D'autres fonctions, et mêmes des extensions entières sont maintenant obsolètes, remplacées par de nouvelles fonctions plus puissantes ou plus efficaces. Certaines fonctions n'ont tout simplement pas été portées pour le moment ou pour des raisons de licences. <<<<<<< migration4.xml Fonctions manquantes pour des raisons de structure Comme PHP 4.0 sépare l'analyse et l'éxécution, il n'est plus possible de modifier le comportement de l'analyseur (intégré dans le moteur Zend) durant l'éxécution, puisque toute l'analyse a eu lieu, et est terminée. La fonction short_tags() a cessé d'exister. Vous pouvez toujours modifier le comportement de l'analyseur avec le fichier php.ini. Une autre fonctionnalité qui a disparu est le débuggeur de PHP 3.0, comme décrit dans un autre appendice. Un nouveau débuggeur est promis par Zend, mais il n'a pas encore montré le bout de son nez. Fonctions et extensions obsolètes Les extensions Adabas et Solid n'existent plus. Elles sont intégrées dans les fonctions ODBC Unifié. Nouveau statut pour <function>unset</function> unset, bient que toujours disponible, a été implémenté légèrement différemment en PHP 4.0, et elle n'est plus vraiment une 'fonction'. Cela n'a pas de conséquence directe sur le comportement de unset, mais utiliser cette fonction pour faire un test avec function_exists retournera FALSE comme il se doit avec les fonction bas niveau comme echo. Une autre application pratique disparue est qu'il n'est plus possible d'appeler unset indirectement, c'est-à-dire que $func="unset"; $func($somevar) ne fonctionne plus. Extensions PHP 3.0 Les extensions écrites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0, ni les exécutables, ni les codes sources. Il n'est pas difficile de porter les extensions de PHP 3.0 à 4.0 si vous avez accès aux sources originales. Une description détaillée du processus de portage ne fait pas partie de cet appendice (pour le moment). Substitution de variables dans les chaînes PHP 4.0 dispose d'un nouveau mécanisme de substitution des variables dans les chaînes. Vous pouvez désormais accéder aux membres d'objets et aux tableaux multidimensionnels dans une chaîne. Pour cela, il suffit de placer la variable entre accolades, le signe $ suivant immédiatement la première accolade : {$variable['a']} Pour utiliser la valeur d'un membre d'objet dans une chaîne, il suffit d'écrire : "text {$obj->member} text"; alors qu'en PHP 3.0, il fallait faire comme ceci : "texte".$objet->membre." texte". Cette technique rend le code beaucoup plus lisible, mais risque de poser des problèmes dans certains scripts PHP 3.0. Vous pouvez facilement traquer ce problème en recherche les séquences {$ dans votre code, et en les remplaçant par \{$ avec votre outil de remplacement habituel. Cookies PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre inverse de celui du code (l'ordre des appels à setcookie). PHP 4.0 rétablit l'ordre naturel en les envoyant dans le même ordre que vous même. Cela peut aussi prendre à contre-pied certains programmes, mais ce comportement était tellement étrange qu'il méritait un tel traitement un jour ou l'autre, pour éviter d'autres problèmes ultérieurs. \ No newline at end of file + + + Migration de PHP 3.0 à PHP 4.0 + + Ce qui a changé en PHP 4.0 + + PHP 4.0 et le moteur Zend ont significativement amélioré les + performances et les possibilités de PHP, tout en assurant une + compatibilité ascendante maximale. Le maximum de codes existants + sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre + code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que + celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront + prêts sans modifications, mais il est bon que vous connaissiez + les quelques différences, et que vous testiez vos applications + avant d'effecteur le changement de cadre de production. Les + indications suivantes vous mettront sur la voie. + + + + Comportement de l'analyseur + + L'analyse et l'éxecution sont désormais deux étapes + complètement dissociées, et l'éxécution + intervient lorsque le code, ainsi que tous ses inclusions et + pré-requis, ont été complètement + analysés et validés. + + + Une des nouvelles conditions introduites est que les fichiers + inclus et requis (include et + require) doivent être syntaxiquement + complets. Vous ne pouvez plus répartir différents cas de votre + code dans plusieurs fichiers. Vous ne pouvez plus commencer une + boucle for ou while, + une condition if ou un cas switch + dans un fichier, et finir la boucle ou placer les cas + else, endif, + case ou break + dans un autre fichier. + + + Il est toujours valable d'inclure du code supplémentaire depuis + une boucle ou dans une condition, mais les accolades de + bloc {...}, et les éléments de la boucle + doivent être dans le même fichier ou chaîne évaluée avec + eval. + + + Cela ne devrait pas perturber trop de monde, car étaler son + code de cette façon est plutôt un style à éviter. + + + Une autre nouveauté est qu'il est plus possible de faire + retourner une valeur avec un fichier requis (require) + (mais c'est plutôt rare en PHP 3.0). Retourner une valeur + avec un fichier inclus (include) est toujours + possible. + + + + Rapport d'erreur + + Changement de configuration + + Avec PHP 3.0, le niveau de rapport d'erreur était obtenu en + ajoutant les constantes numériques de chaque niveau de + rapport. Généralement, on utilisait 15 pour afficher toutes + les erreurs, et 7 pour afficher toutes les erreurs hormis + les alertes simples. + + + PHP 4.0 dispose d'un nombre significativement plus grand de niveaux + de rapport d'erreur, et l'analyseur comprend désormais les + constantes, lors des modifications. + + + Le niveau de rapport d'erreur doit désormais être explicitement + configuré en supprimant les niveaux dont vous ne voulez pas + du niveau maximal, grâce à la fonction de OU exclusif. Ça a + l'air compliqué? Supposons que vous souhaitiez afficher toutes les + erreurs, hormis les alertes de style, qui sont repérées par + la constante : E_NOTICE. Il suffit d'ajouter la valeur + suivante dans le fichier php.ini: + error_reporting = E_ALL & ~ ( E_NOTICE ). + Si vous voulez supprimer en plus les alertes, vous pouvez + ajouter la constante appropriée, en la combinant avec l'opérateur + OU logique '|': + error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING ). + + + + L'utilisation des vieilles valeurs de 7 et 15 est une très + mauvaise idée, car elles ne prennent pas en compte les + nouvelles classes d'erreurs, y compris certaines erreurs + d'analyse. Cela peut conduire à de très étranges résultats, + où le script n'affiche plus rien, malgré une erreur d'analyse. + + + Cela a conduit à un grand nombre de rapport d'erreur dans + le passé, alors que les programmeurs n'étaient tout simplement + pas capables de repérer l'accolade manquante, car l'analyseur + avait la consigne de cacher ces erreurs. + + + Vérifier votre niveau d'erreur doit être le premier réflexe + lorsque vos scripts meurent silencieusement. Le moteur + Zend est considéré actuellement comme suffisamment mature pour + ne plus causer ce genre de problème aujourd'hui. + + + + + Nouveaux messages d'erreurs + + Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui + doivent être considérées comme un très mauvais style, + même s'il effectue bien la tâche qui lui est affectée, car + ils ne sont pas robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans + des situations où PHP 3.0 restera coi. La solution de facilité + consiste à supprimer les messages de niveau E_NOTICE, mais c'est une + meilleure idée de corriger le code à la place. + + + Le cas le plus courant qui génèrera des messages d'alertes + est l'utilisation de constantes sans guillemets comme + index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les + interpréter littéralement comme des chaînes, si aucune constante + n'est définie à la place. Mais si jamais une telle constante + est définie dans une autre partie du code, cela risque de + produire des résultats étonnants. Cela peut devenir un trou + de sécurité si un pirate arrive à redéfinir les constantes + de telle manière que le script lui donne accès à un niveau + de droits supérieur. PHP 4.0 vous signalera tout oubli de + guillemets comme par exemple dans : + $HTTP_SERVER_VARS[REQUEST_METHOD]. Modifier + ce code en $HTTP_SERVER_VARS['REQUEST_METHOD'] + rendra l'analyseur heureux, et améliorera grandement votre + style et la sécurité du code. + + + PHP 4.0 vous signalera les variables ou les + éléments de tableaux non initialisés. + + + + + Initialiseur + + Les variables statiques et les membres de classes n'acceptent + plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait + aussi les expressions. Cela est dû, encore une fois, à la + séparation de l'analyse et de l'exécution : aucun code + ne peut être exécuté tant que l'analyse + n'est pas terminée. + + + Pour les classes, il vaut mieux initialiser les membres dans + le constructeur. Pour les variables statiques, une valeur fixe + et simple est la seule chose qui viennent à l'esprit. + + + + <literal>empty("0")</literal> + + L'évolution la plus polémique est celle de empty. + Une chaîne contenant seulement le caractère + '0' (zéro) est maintenant considérée comme + vide, alors qu'elle ne l'était pas en PHP 3.0. + + + Ce nouveau comportement prend tout son sens dans les applications + web, puisque tous les résultats de champs de type input sont de type + chaîne de caractères, même si un nombre est demandé, + et ce, grâce aux capacités de conversion automatique de PHP. + D'un autre côté, cela peut + casser votre code d'une manière très subtile, menant droit au + comportement erratique, difficilement repérable si vous ne + savez pas ce qui vous attend. + + + + Fonctions manquantes + + Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalités + fonctions et extensions, vous vous rencontrer des fonctions PHP + 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu + être portées en PHP 4.0, maintenant que l'analyse et l'éxécution + ont été séparées. D'autres fonctions, et mêmes des extensions + entières sont maintenant obsolètes, remplacées par de nouvelles + fonctions plus puissantes ou plus efficaces. Certaines fonctions + n'ont tout simplement pas été portées pour le moment ou pour + des raisons de licences. + + + Fonctions manquantes pour des raisons de structure + + Comme PHP 4.0 sépare l'analyse et l'éxécution, il n'est plus + possible de modifier le comportement de l'analyseur (intégré + dans le moteur Zend) durant l'éxécution, puisque toute + l'analyse a eu lieu, et est terminée. La fonction + short_tags() a cessé d'exister. Vous pouvez + toujours modifier le comportement de l'analyseur avec + le fichier php.ini. + + + Une autre fonctionnalité qui a disparu est le débuggeur + de PHP 3.0, comme décrit dans un autre appendice. Un nouveau + débuggeur est promis par Zend, mais il n'a pas encore montré + le bout de son nez. + + + + Fonctions et extensions obsolètes + + Les extensions Adabas et Solid n'existent plus. Elles sont intégrées + dans les fonctions ODBC Unifié. + + + + Nouveau statut pour <function>unset</function> + + unset, bient que toujours disponible, a + été implémenté légèrement + différemment en PHP 4.0, et elle n'est plus vraiment une 'fonction'. + + + Cela n'a pas de conséquence directe sur le comportement de + unset, mais utiliser cette fonction + pour faire un test avec function_exists + retournera FALSE comme il se doit avec + les fonction bas niveau comme echo. + + + Une autre application pratique disparue est qu'il n'est plus possible + d'appeler unset indirectement, c'est-à-dire que + $func="unset"; $func($somevar) ne fonctionne plus. + + + + + Extensions PHP 3.0 + + Les extensions écrites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0, + ni les exécutables, ni les codes sources. Il n'est pas difficile de + porter les extensions de PHP 3.0 à 4.0 si vous avez accès aux + sources originales. Une description détaillée du processus + de portage ne fait pas partie de cet appendice (pour le moment). + + + + Substitution de variables dans les chaînes + + PHP 4.0 dispose d'un nouveau mécanisme de substitution des + variables dans les chaînes. Vous pouvez désormais accéder aux + membres d'objets et aux tableaux multidimensionnels dans une + chaîne. + + + Pour cela, il suffit de placer la variable entre accolades, le signe + $ suivant immédiatement la première accolade : + {$variable['a']} + + + Pour utiliser la valeur d'un membre d'objet dans une chaîne, + il suffit d'écrire : "text {$obj->member} text"; + alors qu'en PHP 3.0, il fallait faire comme ceci : + "texte".$objet->membre." texte". + + + Cette technique rend le code beaucoup plus lisible, mais risque de + poser des problèmes dans certains scripts PHP 3.0. Vous pouvez + facilement traquer ce problème en recherche les séquences + {$ dans votre code, et en les remplaçant par + \{$ avec votre outil de remplacement habituel. + + + + Cookies + + PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre + inverse de celui du code (l'ordre des appels à + setcookie). PHP 4.0 rétablit l'ordre naturel + en les envoyant dans le même ordre que vous même. + + + Cela peut aussi prendre à contre-pied certains programmes, mais + ce comportement était tellement étrange qu'il méritait un tel + traitement un jour ou l'autre, pour éviter d'autres + problèmes ultérieurs. + + + +