HOME Community Articles Code Library People Mail Archive My Account Contribute PHP Jobs

Open Source Database Feature Comparison Matrix Try Declarative Programming with Annotations and Aspects Locate All Stored Procedures and Their Objects/SQL Tables Building a Stored Procedure Generator Making Tables Read-only in Oracle

24-hour Support Daily Backup Dedicated Servers JSP/Java Servlets PHP MySQL Streaming Audio/Video Telnet/SSH Unix Hosting 24-hour Support

Index: phpdoc/fr/appendices/migration4.xml diff -u phpdoc/fr/appendices/migration4.xml:1.6 phpdoc/fr/appendices/migration4.xml:1.7 --- phpdoc/fr/appendices/migration4.xml:1.6 Fri Aug 10 09:20:50 2001 +++ phpdoc/fr/appendices/migration4.xml Thu Oct 18 18:42:07 2001 @@ -1,308 +1 @@ - - - - - - - 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. - - - - - - 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. - - - - - - - - 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. - - - - - - - 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. - - - - - - - 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. - - - - - - 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. - - - - - - 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. - - - - - 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. - - - - - - Les extensions Adabas et Solid n'existent plus. Elles sont intégrées - dans les fonctions ODBC Unifié. - - - - - - 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. - - - - - - - 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). - - - - - - 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. - - - - - - 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. - - - - + 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. Les systèmes d'exploitation récents disposent de capacités de versioning et de scoping. Ces fonctionnalités rendent possible l'installation de PHP 3 et PHP 4 comme modules Apache, simultanément. Ceci a été fait sur les plate-formes suivantes : Linux avec les binutils récents (testé avec binutils 2.9.1.0.25) Solaris 2.5 ou plus récent FreeBSD (testé avec 3.2, 4.0) Pour l'activer, configurez PHP 3 et PHP 4 pour qu'ils utilisent APXS (--with-apxs) et les extensions nécessaires (--enable-versioning). En dehors de cela, toutes les instructions d'installation habituelles s'appliquent. Par exemple : $ ./configure \ --with-apxs=/apache/bin/apxs \ --enable-versioning \ --with-mysql \ --enable-track-vars Le fichier de configuration global, php3.ini, a été renommé en php.ini. Pour les fichiers de configuration Apache, il y a eu des modifications plus importantes. Les types MIME reconnus par le module PHP ont été modifiés. application/x-httpd-php3 --> application/x-httpd-phpapplication/x-httpd-php3-source --> application/x-httpd-php-source Vous pouvez faire fonctionner vos deux versions de PHP avec le même fichier de configuration Apache (suivant la version qui est déjà compilée sur le serveur), en utilisant la syntaxe suivante : AddType application/x-httpd-php3 .php3AddType application/x-httpd-php3-source .php3sAddType application/x-httpd-php .phpAddType application/x-httpd-php-source .phps De plus, les directives de nom de PHP pour Apache ont aussi été modifiées. Depuis PHP 4.0, il n'y a que 4 directives Apache qui se rapportent à PHP : php_value [PHP directive name] [value]php_flag [PHP directive name] [On|Off]php_admin_value [PHP directive name] [value]php_admin_flag [PHP directive name] [On|Off] Il y a deux différences entre les options Admin et les autres valeurs : Les options Admin ne peuvent être placées que des le fichier de configuration général (i.e., httpd.conf). Les valeurs Standard ne peuvent pas contrôler certaines directives PHP. Par exemple, le safe mode (si vous pouviez modifier les configurations dans le fichier .htaccess, cela annulerait toute la sécurité du safe mode. A l'inverse, les valeurs Admin peuvent modifier n'importe quelle directive PHP. Pour rendre le processus de transition plus agréable, PHP 4.0 est distribué avec des scripts qui convertissent automatiquement vos configuration Apache et vos fichiers .htaccess pour qu'ils puissent fonctionner aussi bien avec PHP 3 que PHP 4. Ces scripts ne convertissent PAS les lignes concernant les types MIME. Vous devez le faire vous-même. Pour convertir votre fichier de configuration Apache, exécutez le script apconf-conv.sh (disponible dans le dossier scripts/apache/). Par exemple : ~/php4/scripts/apache:# ./apconf-conv.sh /usr/local/apache/conf/httpd.conf Votre configuration originale sera sauvée dans le fichier httpd.conf.orig. Pour convertir vos fichiers .htaccess, exécutez le script aphtaccess-conv.sh (disponible dans le dossier scripts/apache/). Par exemple : ~/php4/scripts/apache:# find / -name .htaccess -exec ./aphtaccess-conv.sh {} \; De la même façon, votre vieux fichier .htaccess sera sauvé sous le nom .htaccess.orig. Les scripts de conversion requièrent l'installation préalable de awk. 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. 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. 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. 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. 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. 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. 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. Les extensions Adabas et Solid n'existent plus. Elles sont intégrées dans les fonctions ODBC Unifié. 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. 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). 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. 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 Index: phpdoc/fr/appendices/migration.xml diff -u phpdoc/fr/appendices/migration.xml:1.7 phpdoc/fr/appendices/migration.xml:1.8 --- phpdoc/fr/appendices/migration.xml:1.7 Fri Aug 10 09:20:18 2001 +++ phpdoc/fr/appendices/migration.xml Thu Oct 18 18:42:07 2001 @@ -1,356 +1 @@ - - - - - - - PHP 3.0 a été entièrement réécrit. Le nouvel - analyseur syntaxique est beaucoup plus robuste et cohérent qu'en version - 2.0. Il est aussi nettement plus rapide et utilise encore moins de - mémoire. Cependant, ces améliorations n'ont pu être - possible qu'au prix de modifications parfois importantes, tant au niveau des - syntaxes, qu'au niveau des fonctionnalités. - - - De plus, l'équipe de développement PHP a essayé de nettoyer - la syntaxe et les sémantiques, ce qui a aussi causé quelques - incompatibilités. A long terme, nous pensons que ces modifications - seront pour le bien de tous. - - - Ce chapitre va tenter de vous montrer les incompatibilités que vous - pourriez rencontrer lors de votre migration de PHP/FI 2.0 à PHP 3.0 - et de vous aider à les résoudre. Les nouvelles - fonctionnalités ne sont pas signalées, à moins que - cela ne soit nécessaire. - - - Un programme de conversion automatique de vos vieux script PHP/FI 2.0 existe. - Il est disponible dans le dossier de convertisseur de la distribution PHP 3.0. - Ce programme ne fait que repérer les modifications de syntaxe et ne - vous épargnera pas une relecture attentive du script. - - - - - - La première chose que vous remarquerez probablement est que les balises - de PHP start et end ont changé. L'ancienne forme - <? ?> a été remplacée par trois - nouvelles balises possibles : - - - -<?php - echo "Ceci est du code PHP/FI 2.0.\n";? -?> - - - Comme en version 2.0, PHP/FI accepte aussi cette variante : - - - -<?php - echo "Ceci est du code PHP 3.0!\n"; -?> - - - Notez bien que la balise de fin contient désormais un point - d'interrogation et un signe supérieur ">". Cependant, - si vous souhaitez utiliser XML sur votre serveur, vous aurez sûrement - des problèmes avec cette variante, car PHP risque d'essayer - d'exécuter des balises XML. A cause de ceci, la notation - suivante a été ajoutée : - - - -<?php - echo "Ceci est du code PHP 3.0!\n"; -?> - - - Certains d'entre vous rencontrent des problèmes avec les éditeurs qui - ne comprennent pas ce type de balises d'instruction : Microsoft FrontPage - est l'un de ces éditeurs, et, pour contourner le problème, la - variation suivante a été introduite : - - -<script language="php"> - echo "Ceci est du code PHP 3.0!\n"; -</script> - - - - - - - - La syntaxe alternative pour écrire des instructions if/elseif/else, avec if(); - elseif(); else; endif; ne pouvait pas être conservée sans ajouter beaucoup - de complexité à l'analyseur syntaxique. De ce fait, cette syntaxe - à changée : - - - -<?php - if ($foo); - echo "oui\n"; - elseif ($bar); - echo "presque\n"; - else; - echo "non\n"; - endif; -?> - - - - - -<?php - if ($foo): - echo "oui\n"; - elseif ($bar): - echo "presque\n"; - else: - echo "non\n"; - endif; -?> - - - Notez que les points virgules ont été remplacée par des points dans - toutes les commandes, sauf pour la dernière expression (endif). - - - - - - Tout comme pour if..endif, la syntaxe des boucles while..endwhile a changée : - - - -<?php - while ($more_to_come); - ... - endwhile; -?> - - - - -<?php - while ($more_to_come): - ... - endwhile; -?> - - - - - - Attention : si vous utilisez la vieille syntaxe while..endwhile en PHP 3.0, vous - obtiendrez une boucle sans fin ! - - - - - - - PHP/FI 2.0 utilisait le membre à gauche dans les expressions, pour déterminer - le type de résultat attendu. PHP 3.0 prend en compte les deux côtés de - l'expression et cela peut produire des résultats inattendus avec les scripts 2.0. - - - Considérez les lignes suivantes: - - -<?php - $a[0]=5; - $a[1]=7; - $key = key($a); - while ("" != $key) { - echo "$keyn"; - next($a); - } -?> - - - En PHP/FI 2.0, cet exemple va afficher les indices des $a. - En PHP 3.0, l'exemple ne va rien afficher du tout. La raison est qu'en PHP 2.0, puisque - l'argument de gauche est de type chaîne, une comparaison de chaîne était - effectuée et, effectivement, "" n'est pas "", - ce qui conduit la boucle à continuer. En PHP 3, lorsqu'une chaîne est - comparée avec un entier, la comparaison est de type chaîne (la chaîne - est convertie en entier). Ce qui revient à faire la comparaison entre - (atoi("")) qui vaut 0 et la variable - qui vaut aussi 0 et comme 0==0, la boucle ne commence même pas. - - - La correction de ceci est simple : il suffit de remplacer les commandes while par: - - -<?php - while ((string)$key != "") { -?> - - - - - - - - Les messages d'erreur en PHP 3.0 sont généralement plus précis que - ceux de la version 2.0., mais vous ne verrez plus la portion de code qui a causé - l'erreur. A la place, un numéro de ligne et un nom de fichier sera retourné. - - - - - - En PHP 3., l'évaluation des est court-circuité. Cela signifie dans une - expression telle que ((1 || test_me())), la fonction test_me() - ne sera pas exécutée, car cela ne changera pas le résultat. - - - C'est une amélioration mineure, mais qui peut avoir des effets secondaires importants. - - - - - - La plupart des fonctions internes de PHP ont été - réécrite pour qu'elle retourne &true; en cas de succès, - et &false; en cas d'erreur, au contraire des fonctions qui retournaient 0 et -1 - en PHP/FI 2.0. Le nouveau comportement est beaucoup plus logique, comme par - exemple $fp = fopen("/your/file") or fail("fichier non trouvé!");. - Etant donné que PHP/FI 2.0 n'a pas de règle claire à - propos de ce que les fonctions doivent retourner en cas d'échec, la - plupart des scripts devront probablement être vérifié - manuellement, après avoir utilisé le convertisseur 2.0 à - 3.0. - - - - - -<?php - $fp = fopen($file, "r"); - if ($fp == -1); - echo("Impossible d'ouvrir le fichier $file en lecture <br>\n"); - endif; -?> - - - - - -<?php - $fp =  <email protected>($file, "r") or - print("Impossible d'ouvrir le fichier $file en lecture<br>\n"); -?> - - - - - - - - - - Le module PHP 3.0 pour Apache n'accepte plus les versions d'Apache antérieure - à la version 1.2. Apache 1.2 ou plus récent est nécessaire. - - - - - echo n'utilise plus de chaîne de formatage. Il faut - utiliser printf à la place. - - - - - En PHP/FI 2.0, un effet secondaire de l'implémentation faisait que - $foo[0] était la même chose que - $foo. Ce n'est plus vrai en PHP 3.0. - - - - - Lire un tableau avec $array[] n'est plus valable. - - - Ainsi, il n'est plus possible de passer en revue un tableau avec des - boucles telles que $data = $array[]. Utilisez - current et next à la place. - - - Ainsi, $array1[] = $array2 n'ajoute pas les valeurs - de $array2 à $array1, - mais crée un nouvel élément dans $array1 - et y affecte $array2 comme dernier élément. - Voir aussi les tableaux multidimensionnels. - - - - - "+" n'est plus utilisable comme opérateur de - concaténation de chaîne. A la place, il convertit les - arguments en nombres et effectue une addition numérique. - Utilisez "." à la place. - - - - - - -<?php - echo "1" + "1"; -?> - - - En PHP 2.0 cela retournerait 11, en PHP 3.0 cela va retourner 2. A la place, - faites : - -<?php - echo "1"."1"; -?> - - -<?php - $a = 1; - $b = 1; - echo $a + $b; -?> - - - - Cela va afficher 2, tant en PHP 2.0 qu'en 3.0. - -<?php - $a = 1; - $b = 1; - echo $a.$b; -?> - - Cela va afficher 11 en PHP 3.0. - - - - - + PHP 3.0 a été entièrement réécrit. Le nouvel analyseur syntaxique est beaucoup plus robuste et cohérent qu'en version 2.0. Il est aussi nettement plus rapide et utilise encore moins de mémoire. Cependant, ces améliorations n'ont pu être possible qu'au prix de modifications parfois importantes, tant au niveau des syntaxes, qu'au niveau des fonctionnalités. De plus, l'équipe de développement PHP a essayé de nettoyer la syntaxe et les sémantiques, ce qui a aussi causé quelques incompatibilités. A long terme, nous pensons que ces modifications seront pour le bien de tous. Ce chapitre va tenter de vous montrer les incompatibilités que vous pourriez rencontrer lors de votre migration de PHP/FI 2.0 à PHP 3.0 et de vous aider à les résoudre. Les nouvelles fonctionnalités ne sont pas signalées, à moins que cela ne soit nécessaire. Un programme de conversion automatique de vos vieux script PHP/FI 2.0 existe. Il est disponible dans le dossier de convertisseur de la distribution PHP 3.0. Ce programme ne fait que repérer les modifications de syntaxe et ne vous épargnera pas une relecture attentive du script. La première chose que vous remarquerez probablement est que les balises de PHP start et end ont changé. L'ancienne forme <? ?> a été remplacée par trois nouvelles balises possibles : <?php echo "Ceci est du code PHP/FI 2.0.\n";??> Comme en version 2.0, PHP/FI accepte aussi cette variante : <?php echo "Ceci est du code PHP 3.0!\n";?> Notez bien que la balise de fin contient désormais un point d'interrogation et un signe supérieur ">". Cependant, si vous souhaitez utiliser XML sur votre serveur, vous aurez sûrement des problèmes avec cette variante, car PHP risque d'essayer d'exécuter des balises XML. A cause de ceci, la notation suivante a été ajoutée : <?php echo "Ceci est du code PHP 3.0!\n";?> Certains d'entre vous rencontrent des problèmes avec les éditeurs qui ne comprennent pas ce type de balises d'instruction : Microsoft FrontPage est l'un de ces éditeurs, et, pour contourner le problème, la variation suivante a été introduite : <script language="php"> echo "Ceci est du code PHP 3.0!\n";</script> La syntaxe alternative pour écrire des instructions if/elseif/else, avec if(); elseif(); else; endif; ne pouvait pas être conservée sans ajouter beaucoup de complexité à l'analyseur syntaxique. De ce fait, cette syntaxe à changée : <?php if ($foo); echo "oui\n"; elseif ($bar); echo "presque\n"; else; echo "non\n"; endif;?> <?php if ($foo): echo "oui\n"; elseif ($bar): echo "presque\n"; else: echo "non\n"; endif;?> Notez que les points virgules ont été remplacée par des points dans toutes les commandes, sauf pour la dernière expression (endif). Tout comme pour if..endif, la syntaxe des boucles while..endwhile a changée : <?php while ($more_to_come); ... endwhile;?> <?php while ($more_to_come): ... endwhile;?> Attention : si vous utilisez la vieille syntaxe while..endwhile en PHP 3.0, vous obtiendrez une boucle sans fin ! PHP/FI 2.0 utilisait le membre à gauche dans les expressions, pour déterminer le type de résultat attendu. PHP 3.0 prend en compte les deux côtés de l'expression et cela peut produire des résultats inattendus avec les scripts 2.0. Considérez les lignes suivantes: <?php $a[0]=5; $a[1]=7; $key = key($a); while ("" != $key) { echo "$keyn"; next($a); }?> En PHP/FI 2.0, cet exemple va afficher les indices des $a. En PHP 3.0, l'exemple ne va rien afficher du tout. La raison est qu'en PHP 2.0, puisque l'argument de gauche est de type chaîne, une comparaison de chaîne était effectuée et, effectivement, "" n'est pas "", ce qui conduit la boucle à continuer. En PHP 3, lorsqu'une chaîne est comparée avec un entier, la comparaison est de type chaîne (la chaîne est convertie en entier). Ce qui revient à faire la comparaison entre (atoi("")) qui vaut 0 et la variable qui vaut aussi 0 et comme 0==0, la boucle ne commence même pas. La correction de ceci est simple : il suffit de remplacer les commandes while par: <?php while ((string)$key != "") {?> Les messages d'erreur en PHP 3.0 sont généralement plus précis que ceux de la version 2.0., mais vous ne verrez plus la portion de code qui a causé l'erreur. A la place, un numéro de ligne et un nom de fichier sera retourné. En PHP 3., l'évaluation des est court-circuité. Cela signifie dans une expression telle que ((1 || test_me())), la fonction test_me() ne sera pas exécutée, car cela ne changera pas le résultat. C'est une amélioration mineure, mais qui peut avoir des effets secondaires importants. La plupart des fonctions internes de PHP ont été réécrite pour qu'elle retourne &true; en cas de succès, et &false; en cas d'erreur, au contraire des fonctions qui retournaient 0 et -1 en PHP/FI 2.0. Le nouveau comportement est beaucoup plus logique, comme par exemple $fp = fopen("/your/file") or fail("fichier non trouvé!");. Etant donné que PHP/FI 2.0 n'a pas de règle claire à propos de ce que les fonctions doivent retourner en cas d'échec, la plupart des scripts devront probablement être vérifié manuellement, après avoir utilisé le convertisseur 2.0 à 3.0. <?php $fp = fopen($file, "r"); if ($fp == -1); echo("Impossible d'ouvrir le fichier $file en lecture <br>\n"); endif;?> <?php $fp =  <email protected>($file, "r") or print("Impossible d'ouvrir le fichier $file en lecture<br>\n");?> Le module PHP 3.0 pour Apache n'accepte plus les versions d'Apache antérieure à la version 1.2. Apache 1.2 ou plus récent est nécessaire. echo n'utilise plus de chaîne de formatage. Il faut utiliser printf à la place. En PHP/FI 2.0, un effet secondaire de l'implémentation faisait que $foo[0] était la même chose que $foo. Ce n'est plus vrai en PHP 3.0. Lire un tableau avec $array[] n'est plus valable. Ainsi, il n'est plus possible de passer en revue un tableau avec des boucles telles que $data = $array[]. Utilisez current et next à la place. Ainsi, $array1[] = $array2 n'ajoute pas les valeurs de $array2 à $array1, mais crée un nouvel élément dans $array1 et y affecte $array2 comme dernier élément. Voir aussi les tableaux multidimensionnels. "+" n'est plus utilisable comme opérateur de concaténation de chaîne. A la place, il convertit les arguments en nombres et effectue une addition numérique. Utilisez "." à la place. <?php echo "1" + "1";?> En PHP 2.0 cela retournerait 11, en PHP 3.0 cela va retourner 2. A la place, faites : <?php echo "1"."1";?> <?php $a = 1; $b = 1; echo $a + $b;?> Cela va afficher 2, tant en PHP 2.0 qu'en 3.0. <?php $a = 1; $b = 1; echo $a.$b;?> Cela va afficher 11 en PHP 3.0. \ No newline at end of file