cvs: phpdoc /fr/appendices migration.xml migration4.xml
| From: | Damien Seguy | Date: | Thu, 18 Oct 2001 22:42:08 +0000 |
| Subject: | cvs: phpdoc /fr/appendices migration.xml migration4.xml | ||
| Groups: | php.doc | ||
| Request: | Send a blank email to phpdoc+get-969338085@lists.php.net to get a copy of this message | ||
dams Thu Oct 18 18:42:08 2001 EDT
Modified files:
/phpdoc/fr/appendices migration4.xml migration.xml
Log:
Added september update.
synch with tree
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 @@ -<!-- $Revision: 1.6 $ --> - <appendix id="migration4"> - <title>Migration de PHP 3.0 à PHP 4.0</title> - <sect1 id="migration4.changes"> - <title>Ce qui a changé en PHP 4.0</title> - <para> - 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. - </para> - </sect1> - <sect1 id="migration4.parser"> - <title>Comportement de l'analyseur</title> - <para> - 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. - </para> - <para> - Une des nouvelles conditions introduites est que les fichiers - inclus et requis (<function>include</function> et - <function>require</function>) 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 <literal>for</literal> ou <literal>while</literal>, - une condition <literal>if</literal> ou un cas <literal>switch</literal> - dans un fichier, et finir la boucle ou placer les cas - <literal>else</literal>, <literal>endif</literal>, - <literal>case</literal> ou <literal>break</literal> - dans un autre fichier. - </para> - <para> - Il est toujours valable d'inclure du code supplémentaire depuis - une boucle ou dans une condition, mais les accolades de - bloc <literal>{...}</literal>, et les éléments de la boucle - doivent être dans le même fichier ou chaîne évaluée avec - <function>eval</function>. - </para> - <para> - Cela ne devrait pas perturber trop de monde, car étaler son - code de cette façon est plutôt un style à éviter. - </para> - <para> - Une autre nouveauté est qu'il est plus possible de faire - retourner une valeur avec un fichier requis (<function>require</function>) - (mais c'est plutôt rare en PHP 3.0). Retourner une valeur - avec un fichier inclus (<function>include</function>) est toujours - possible. - </para> - </sect1> - <sect1 id="migration4.errors"> - <title>Rapport d'erreur</title> - <sect2 id="migration4.error_reporting"> - <title>Changement de configuration</title> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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 <filename>php.ini</filename>: - <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>. - Si vous voulez supprimer en plus les alertes, vous pouvez - ajouter la constante appropriée, en la combinant avec l'opérateur - OU logique '|': - <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>. - </para> - <warning> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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. - </para> - </warning> - </sect2> - <sect2 id="migration4.messages"> - <title>Nouveaux messages d'erreurs</title> - <para> - 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. - </para> - <para> - 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 : - <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier - ce code en <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal> - rendra l'analyseur heureux, et améliorera grandement votre - style et la sécurité du code. - </para> - <para> - PHP 4.0 vous signalera les variables ou les - éléments de tableaux non initialisés. - </para> - </sect2> - </sect1> - <sect1 id="migration4.initializers"> - <title>Initialiseur</title> - <para> - 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. - </para> - <para> - 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. - </para> - </sect1> - <sect1 id="migration4.empty"> - <title><literal>empty("0")</literal></title> - <para> - L'évolution la plus polémique est celle de <function>empty</function>. - Une chaîne contenant seulement le caractère - <literal>'0'</literal> (zéro) est maintenant considérée comme - vide, alors qu'elle ne l'était pas en PHP 3.0. - </para> - <para> - 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. - </para> - </sect1> - <sect1 id="migration4.missing"> - <title>Fonctions manquantes</title> - <para> - 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. - </para> - <sect2 id="migration4.impossible"> - <title>Fonctions manquantes pour des raisons de structure</title> - <para> - 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 <filename>php.ini</filename>. - </para> - <para> - 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. - </para> - </sect2> - <sect2 id="migration4.deprecated"> - <title>Fonctions et extensions obsolètes</title> - <para> - Les extensions Adabas et Solid n'existent plus. Elles sont intégrées - dans les fonctions <link linkend="ref.odbc">ODBC Unifié</link>. - </para> - </sect2> - <sect2 id="migration4.unset"> - <title>Nouveau statut pour <function>unset</function></title> - <para> - <function>unset</function>, 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'. - </para> - <para> - Cela n'a pas de conséquence directe sur le comportement de - <function>unset</function>, mais utiliser cette fonction - pour faire un test avec <function>function_exists</function> - retournera <literal>FALSE</literal> comme il se doit avec - les fonction bas niveau comme <function>echo</function>. - </para> - <para> - Une autre application pratique disparue est qu'il n'est plus possible - d'appeler <function>unset</function> indirectement, c'est-à-dire que - <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus. - </para> - </sect2> - </sect1> - <sect1 id="migration4.extension"> - <title>Extensions PHP 3.0</title> - <para> - 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). - </para> - </sect1> - <sect1 id="migration4.substitution"> - <title>Substitution de variables dans les chaînes</title> - <para> - 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. - </para> - <para> - Pour cela, il suffit de placer la variable entre accolades, le signe - $ suivant immédiatement la première accolade : - <literal>{$variable['a']}</literal> - </para> - <para> - Pour utiliser la valeur d'un membre d'objet dans une chaîne, - il suffit d'écrire : <literal>"text {$obj->member} text"</literal>; - alors qu'en PHP 3.0, il fallait faire comme ceci : - <literal>"texte".$objet->membre." texte"</literal>. - </para> - <para> - 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 - <literal>{$</literal> dans votre code, et en les remplaçant par - <literal>\{$</literal> avec votre outil de remplacement habituel. - </para> - </sect1> - <sect1 id="migration4.cookies"> - <title>Cookies</title> - <para> - PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre - inverse de celui du code (l'ordre des appels à - <function>setcookie</function>). PHP 4.0 rétablit l'ordre naturel - en les envoyant dans le même ordre que vous même. - </para> - <para> - 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. - </para> - </sect1> - </appendix> -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-omittag:t -sgml-shorttag:t -sgml-minimize-attributes:nil -sgml-always-quote-attributes:t -sgml-indent-step:1 -sgml-indent-data:t -sgml-parent-document:nil -sgml-default-dtd-file:"../../manual.ced" -sgml-exposed-tags:nil -sgml-local-catalogs:nil -sgml-local-ecat-files:nil -End: ---> +<?xml encoding="iso-8859-1"?><!-- $Revision: 1.7 $ --> <appendix id="migration4"> <title>Migration de PHP 3.0 à PHP 4.0</title> <sect1 id="migration4.changes"> <title>Ce qui a changé en PHP 4.0</title> <para> 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. </para> </sect1> <sect1 id="migration4.php4.with.php3"> <title>Utiliser PHP 3 et PHP 4 simultanément</title> <simpara> 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. </simpara> <simpara> Ceci a été fait sur les plate-formes suivantes : </simpara> <itemizedlist> <listitem> <simpara> Linux avec les binutils récents (testé avec binutils 2.9.1.0.25) </simpara> </listitem> <listitem> <simpara> Solaris 2.5 ou plus récent </simpara> </listitem> <listitem> <simpara> FreeBSD (testé avec 3.2, 4.0) </simpara> </listitem> </itemizedlist> <para> Pour l'activer, configurez PHP 3 et PHP 4 pour qu'ils utilisent APXS (<link linkend="install.configure.with-apxs"><option role="configure">--with-apxs</option></link>) et les extensions nécessaires (<link linkend="install.configure.enable-versioning"><option role="configure">--enable-versioning</option></link>). En dehors de cela, toutes les instructions d'installation habituelles s'appliquent. Par exemple : <informalexample> <programlisting>$ ./configure \ --with-apxs=/apache/bin/apxs \ --enable-versioning \ --with-mysql \ --enable-track-vars </programlisting> </informalexample> </para> </sect1> <sect1 id="migration4.configuration"> <title>Migration des fichiers de configuration</title> <para> Le fichier de configuration global, <filename>php3.ini</filename>, a été renommé en <filename>php.ini</filename>. </para> <para> 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. <informalexample> <programlisting>application/x-httpd-php3 --> application/x-httpd-phpapplication/x-httpd-php3-source --> application/x-httpd-php-source </programlisting> </informalexample> </para> <para> 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 : <informalexample> <programlisting>AddType application/x-httpd-php3 .php3AddType application/x-httpd-php3-source .php3sAddType application/x-httpd-php .phpAddType application/x-httpd-php-source .phps </programlisting> </informalexample> </para> <simpara> De plus, les directives de nom de PHP pour Apache ont aussi été modifiées. </simpara> <para> Depuis PHP 4.0, il n'y a que 4 directives Apache qui se rapportent à PHP : <informalexample> <programlisting>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] </programlisting> </informalexample> </para> <simpara> Il y a deux différences entre les options Admin et les autres valeurs : </simpara> <itemizedlist> <listitem> <simpara> Les options Admin ne peuvent être placées que des le fichier de configuration général (i.e., httpd.conf). </simpara> </listitem> <listitem> <simpara> 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 <filename>.htaccess</filename>, cela annulerait toute la sécurité du safe mode. A l'inverse, les valeurs Admin peuvent modifier n'importe quelle directive PHP. </simpara> </listitem> </itemizedlist> <simpara> 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 <filename>.htaccess</filename> 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. </simpara> <para> Pour convertir votre fichier de configuration Apache, exécutez le script <filename>apconf-conv.sh</filename> (disponible dans le dossier <filename>scripts/apache/</filename>). Par exemple : <informalexample> <programlisting>~/php4/scripts/apache:# ./apconf-conv.sh /usr/local/apache/conf/httpd.conf </programlisting> </informalexample> </para> <simpara> Votre configuration originale sera sauvée dans le fichier <filename>httpd.conf.orig</filename>. </simpara> <para> Pour convertir vos fichiers <filename>.htaccess</filename>, exécutez le script <filename>aphtaccess-conv.sh</filename> (disponible dans le dossier <filename>scripts/apache/</filename>). Par exemple : <informalexample> <programlisting>~/php4/scripts/apache:# find / -name .htaccess -exec ./aphtaccess-conv.sh {} \; </programlisting> </informalexample> </para> <simpara> De la même façon, votre vieux fichier <filename>.htaccess</filename> sera sauvé sous le nom <filename>.htaccess.orig</filename>. </simpara> <simpara> Les scripts de conversion requièrent l'installation préalable de awk. </simpara> </sect1> <sect1 id="migration4.parser"> <title>Comportement de l'analyseur</title> <para> 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. </para> <para> Une des nouvelles conditions introduites est que les fichiers inclus et requis (<function>include</function> et <function>require</function>) 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 <literal>for</literal> ou <literal>while</literal>, une condition <literal>if</literal> ou un cas <literal>switch</literal> dans un fichier, et finir la boucle ou placer les cas <literal>else</literal>, <literal>endif</literal>, <literal>case</literal> ou <literal>break</literal> dans un autre fichier. </para> <para> Il est toujours valable d'inclure du code supplémentaire depuis une boucle ou dans une condition, mais les accolades de bloc <literal>{...}</literal>, et les éléments de la boucle doivent être dans le même fichier ou chaîne évaluée avec <function>eval</function>. </para> <para> Cela ne devrait pas perturber trop de monde, car étaler son code de cette façon est plutôt un style à éviter. </para> <para> Une autre nouveauté est qu'il est plus possible de faire retourner une valeur avec un fichier requis (<function>require</function>) (mais c'est plutôt rare en PHP 3.0). Retourner une valeur avec un fichier inclus (<function>include</function>) est toujours possible. </para> </sect1> <sect1 id="migration4.error-reporting"> <title>Rapport d'erreur</title> <sect2 id="migration4.error-reporting.config"> <title>Changement de configuration</title> <para> 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. </para> <para> 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. </para> <para> 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 <filename>php.ini</filename>: <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>. Si vous voulez supprimer en plus les alertes, vous pouvez ajouter la constante appropriée, en la combinant avec l'opérateur OU logique '|': <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>. </para> <warning> <para> 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. </para> <para> 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. </para> <para> 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. </para> </warning> </sect2> <sect2 id="migration4.error-reporting.additions"> <title>Nouveaux messages d'erreurs</title> <para> 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. </para> <para> 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 : <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier ce code en <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal> rendra l'analyseur heureux, et améliorera grandement votre style et la sécurité du code. </para> <para> PHP 4.0 vous signalera les variables ou les éléments de tableaux non initialisés. </para> </sect2> </sect1> <sect1 id="migration4.initializers"> <title>Initialiseur</title> <para> 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. </para> <para> 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. </para> </sect1> <sect1 id="migration4.empty"> <title><literal>empty("0")</literal></title> <para> L'évolution la plus polémique est celle de <function>empty</function>. Une chaîne contenant seulement le caractère <literal>'0'</literal> (zéro) est maintenant considérée comme vide, alors qu'elle ne l'était pas en PHP 3.0. </para> <para> 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. </para> </sect1> <sect1 id="migration4.missing"> <title>Fonctions manquantes</title> <para> 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. </para> <sect2 id="migration4.missing.concept"> <title>Fonctions manquantes pour des raisons de structure</title> <para> 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 <filename>php.ini</filename>. </para> <para> 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. </para> </sect2> <sect2 id="migration4.deprecate"> <title>Fonctions et extensions obsolètes</title> <para> Les extensions Adabas et Solid n'existent plus. Elles sont intégrées dans les fonctions <link linkend="ref.odbc">ODBC Unifié</link>. </para> </sect2> <sect2 id="migration4.unset"> <title>Nouveau statut pour <function>unset</function></title> <para> <function>unset</function>, 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'. </para> <para> Cela n'a pas de conséquence directe sur le comportement de <function>unset</function>, mais utiliser cette fonction pour faire un test avec <function>function_exists</function> retournera <literal>FALSE</literal> comme il se doit avec les fonction bas niveau comme <function>echo</function>. </para> <para> Une autre application pratique disparue est qu'il n'est plus possible d'appeler <function>unset</function> indirectement, c'est-à-dire que <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus. </para> </sect2> </sect1> <sect1 id="migration4.extensions"> <title>Extensions PHP 3.0</title> <para> 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). </para> </sect1> <sect1 id="migration4.string"> <title>Substitution de variables dans les chaînes</title> <para> 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. </para> <para> Pour cela, il suffit de placer la variable entre accolades, le signe $ suivant immédiatement la première accolade : <literal>{$variable['a']}</literal> </para> <para> Pour utiliser la valeur d'un membre d'objet dans une chaîne, il suffit d'écrire : <literal>"text {$obj->member} text"</literal>; alors qu'en PHP 3.0, il fallait faire comme ceci : <literal>"texte".$objet->membre." texte"</literal>. </para> <para> 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 <literal>{$</literal> dans votre code, et en les remplaçant par <literal>\{$</literal> avec votre outil de remplacement habituel. </para> </sect1> <sect1 id="migration4.cookies"> <title>Cookies</title> <para> PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre inverse de celui du code (l'ordre des appels à <function>setcookie</function>). PHP 4.0 rétablit l'ordre naturel en les envoyant dans le même ordre que vous même. </para> <para> 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. </para> </sect1> </appendix><!-- Keep this comment at the end of the fileLocal variables:mode: sgmlsgml-omittag:tsgml-shorttag:tsgml-minimize-attributes:nilsgml-always-quote-attributes:tsgml-indent-step:1sgml-indent-data:tsgml-parent-document:nilsgml-default-dtd-file:"../../manual.ced"sgml-exposed-tags:nilsgml-local-catalogs:nilsgml-local-ecat-files:nilEnd:--> \ 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 @@ -<!-- $Revision: 1.7 $ --> -<appendix id="migration"> - <title>Migration de PHP/FI 2.0 à PHP 3.0</title> - <sect1 id="migration-about"> - <title>A propos des incompatibilités en 3.0</title> - <simpara> - 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. - </simpara> - <simpara> - 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. - </simpara> - <simpara> - 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. - </simpara> - <simpara> - 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. - </simpara> - </sect1> - <sect1 id="migration-startendtags"> - <title>Balises PHP</title> - <para> - La première chose que vous remarquerez probablement est que les balises - de PHP start et end ont changé. L'ancienne forme - <literal><? ?></literal> a été remplacée par trois - nouvelles balises possibles : - <example> - <title>Migration: Migration: balises start/end </title> - <programlisting role="php"> -<?php - echo "Ceci est du code PHP/FI 2.0.\n";? -?> - </programlisting> - </example> - Comme en version 2.0, PHP/FI accepte aussi cette variante : - <example> - <title>Migration: premières nouvelles balises PHP</title> - <programlisting role="php"> -<?php - echo "Ceci est du code PHP 3.0!\n"; -?> - </programlisting> - </example> - 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 : - <example> - <title>Migration: Nouvelles balises PHP</title> - <programlisting role="php"> -<?php - echo "Ceci est du code PHP 3.0!\n"; -?> - </programlisting> - </example> - 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 : - <example><title>Nouvelles balises PHP</title> - <programlisting role="php"> -<script language="php"> - echo "Ceci est du code PHP 3.0!\n"; -</script> - </programlisting> - </example> - </para> - </sect1> - <sect1 id="migration-if-endif"> - <title>Syntaxe if..endif</title> - <para> - 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 : - <example> - <title>Migration: ancienne syntaxe if..endif </title> - <programlisting role="php"> -<?php - if ($foo); - echo "oui\n"; - elseif ($bar); - echo "presque\n"; - else; - echo "non\n"; - endif; -?> - </programlisting> - </example> - <example> - <title>Migration: nouvelle syntaxe if..endif</title> - <programlisting role="php"> -<?php - if ($foo): - echo "oui\n"; - elseif ($bar): - echo "presque\n"; - else: - echo "non\n"; - endif; -?> - </programlisting> - </example> - Notez que les points virgules ont été remplacée par des points dans - toutes les commandes, sauf pour la dernière expression (endif). - </para> - </sect1> - <sect1 id="migration-while"> - <title>Syntaxe while</title> - <para> - Tout comme pour if..endif, la syntaxe des boucles while..endwhile a changée : - <example> - <title>Migration: ancienne syntaxe while..endwhile </title> - <programlisting role="php"> -<?php - while ($more_to_come); - ... - endwhile; -?> - </programlisting> - </example> - <example><title>Migration: nouvelle syntaxe while..endwhile</title> - <programlisting role="php"> -<?php - while ($more_to_come): - ... - endwhile; -?> - </programlisting> - </example> - </para> - <warning> - <simpara> - Attention : si vous utilisez la vieille syntaxe while..endwhile en PHP 3.0, vous - obtiendrez une boucle sans fin ! - </simpara> - </warning> - </sect1> - <sect1 id="migration-expr"> - <title>Types d'expression</title> - <simpara> - 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. - </simpara> - <para> - Considérez les lignes suivantes: - <informalexample> - <programlisting role="php"> -<?php - $a[0]=5; - $a[1]=7; - $key = key($a); - while ("" != $key) { - echo "$keyn"; - next($a); - } -?> - </programlisting> - </informalexample> - 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, <literal>""</literal> n'est pas <literal>""</literal>, - 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 - (<literal>atoi("")</literal>) qui vaut <literal>0</literal> et la variable - qui vaut aussi 0 et comme 0==0, la boucle ne commence même pas. - </para> - <para> - La correction de ceci est simple : il suffit de remplacer les commandes while par: - <informalexample> - <programlisting role="php"> -<?php - while ((string)$key != "") { -?> - </programlisting> - </informalexample> - </para> - </sect1> - <sect1 id="migration-errors"> - <title>Les messages d'erreur ont changé</title> - <simpara> - 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é. - </simpara> - </sect1> - <sect1 id="migration-booleval"> - <title>Evaluation rapide des booléens </title> - <simpara> - En PHP 3., l'évaluation des est court-circuité. Cela signifie dans une - expression telle que (<literal>(1 || test_me())</literal>), la fonction test_me() - ne sera pas exécutée, car cela ne changera pas le résultat. - </simpara> - <simpara> - C'est une amélioration mineure, mais qui peut avoir des effets secondaires importants. - </simpara> - </sect1> - <sect1 id="migration-truefalse"> - <title>La valeur &true;/&false; comme retour de fonctions</title> - <simpara> - 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. - </simpara> - <para> - <example> - <title> - Migration depuis 2.0: valeur retournées, ancienne façon - </title> - <programlisting role="php"> -<?php - $fp = fopen($file, "r"); - if ($fp == -1); - echo("Impossible d'ouvrir le fichier $file en lecture <br>\n"); - endif; -?> - </programlisting> - </example> - <example> - <title>Migration depuis 2.0: valeur retournées, nouvelle façon</title> - <programlisting role="php"> -<?php - $fp = @fopen($file, "r") or - print("Impossible d'ouvrir le fichier $file en lecture<br>\n"); -?> - </programlisting> - </example> - </para> - </sect1> - <sect1 id="migration-other"> - <title>Diverses incompatibilités</title> - <itemizedlist> - <listitem> - <simpara> - 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. - </simpara> - </listitem> - <listitem> - <simpara> - <function>echo</function> n'utilise plus de chaîne de formatage. Il faut - utiliser <function>printf</function> à la place. - </simpara> - </listitem> - <listitem> - <simpara> - En PHP/FI 2.0, un effet secondaire de l'implémentation faisait que - <literal>$foo[0]</literal> était la même chose que - <literal>$foo</literal>. Ce n'est plus vrai en PHP 3.0. - </simpara> - </listitem> - <listitem> - <simpara> - Lire un tableau avec $array[] n'est plus valable. - </simpara> - <simpara> - Ainsi, il n'est plus possible de passer en revue un tableau avec des - boucles telles que <literal>$data = $array[]</literal>. Utilisez - <function>current</function> et <function>next</function> à la place. - </simpara> - <simpara> - Ainsi, <literal>$array1[] = $array2</literal> n'ajoute pas les valeurs - de <literal>$array2</literal> à <literal>$array1</literal>, - mais crée un nouvel élément dans <literal>$array1</literal> - et y affecte <literal>$array2</literal> comme dernier élément. - Voir aussi les tableaux multidimensionnels. - </simpara> - </listitem> - <listitem> - <simpara> - <literal>"+"</literal> 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 <literal>"."</literal> à la place. - </simpara> - </listitem> - </itemizedlist> - <example> - <title>Migration depuis 2.0: concaténation de chaînes</title> - <programlisting role="php"> -<?php - echo "1" + "1"; -?> - </programlisting> - <para> - En PHP 2.0 cela retournerait 11, en PHP 3.0 cela va retourner 2. A la place, - faites : - <programlisting role="php"> -<?php - echo "1"."1"; -?> - </programlisting> - <programlisting role="php"> -<?php - $a = 1; - $b = 1; - echo $a + $b; -?> - </programlisting> - </para> - <para> - Cela va afficher 2, tant en PHP 2.0 qu'en 3.0. - <programlisting role="php"> -<?php - $a = 1; - $b = 1; - echo $a.$b; -?> - </programlisting> - Cela va afficher 11 en PHP 3.0. - </para> - </example> - </sect1> - </appendix> -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-omittag:t -sgml-shorttag:t -sgml-minimize-attributes:nil -sgml-always-quote-attributes:t -sgml-indent-step:1 -sgml-indent-data:t -sgml-parent-document:nil -sgml-default-dtd-file:"../manual.ced" -sgml-exposed-tags:nil -sgml-local-catalogs:nil -sgml-local-ecat-files:nil -End: ---> +<?xml encoding="iso-8859-1"?><!-- $Revision: 1.8 $ --><appendix id="migration"> <title>Migration de PHP/FI 2.0 à PHP 3.0</title> <sect1 id="migration.about"> <title>A propos des incompatibilités en 3.0</title> <simpara> 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. </simpara> <simpara> 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. </simpara> <simpara> 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. </simpara> <simpara> 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. </simpara> </sect1> <sect1 id="migration.startendtags"> <title>Balises PHP</title> <para> La première chose que vous remarquerez probablement est que les balises de PHP start et end ont changé. L'ancienne forme <literal><? ?></literal> a été remplacée par trois nouvelles balises possibles : <example> <title>Migration: Migration: balises start/end </title> <programlisting role="php"><?php echo "Ceci est du code PHP/FI 2.0.\n";??> </programlisting> </example> Comme en version 2.0, PHP/FI accepte aussi cette variante : <example> <title>Migration: premières nouvelles balises PHP</title> <programlisting role="php"><?php echo "Ceci est du code PHP 3.0!\n";?> </programlisting> </example> 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 : <example> <title>Migration: Nouvelles balises PHP</title> <programlisting role="php"><?php echo "Ceci est du code PHP 3.0!\n";?> </programlisting> </example> 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 : <example><title>Nouvelles balises PHP</title> <programlisting role="php"><script language="php"> echo "Ceci est du code PHP 3.0!\n";</script> </programlisting> </example> </para> </sect1> <sect1 id="migration.if-endif"> <title>Syntaxe if..endif</title> <para> 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 : <example> <title>Migration: ancienne syntaxe if..endif </title> <programlisting role="php"><?php if ($foo); echo "oui\n"; elseif ($bar); echo "presque\n"; else; echo "non\n"; endif;?> </programlisting> </example> <example> <title>Migration: nouvelle syntaxe if..endif</title> <programlisting role="php"><?php if ($foo): echo "oui\n"; elseif ($bar): echo "presque\n"; else: echo "non\n"; endif;?> </programlisting> </example> Notez que les points virgules ont été remplacée par des points dans toutes les commandes, sauf pour la dernière expression (endif). </para> </sect1> <sect1 id="migration.while"> <title>Syntaxe while</title> <para> Tout comme pour if..endif, la syntaxe des boucles while..endwhile a changée : <example> <title>Migration: ancienne syntaxe while..endwhile </title> <programlisting role="php"><?php while ($more_to_come); ... endwhile;?> </programlisting> </example> <example><title>Migration: nouvelle syntaxe while..endwhile</title> <programlisting role="php"><?php while ($more_to_come): ... endwhile;?> </programlisting> </example> </para> <warning> <simpara> Attention : si vous utilisez la vieille syntaxe while..endwhile en PHP 3.0, vous obtiendrez une boucle sans fin ! </simpara> </warning> </sect1> <sect1 id="migration.expr"> <title>Types d'expression</title> <simpara> 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. </simpara> <para> Considérez les lignes suivantes: <informalexample> <programlisting role="php"><?php $a[0]=5; $a[1]=7; $key = key($a); while ("" != $key) { echo "$keyn"; next($a); }?> </programlisting> </informalexample> 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, <literal>""</literal> n'est pas <literal>""</literal>, 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 (<literal>atoi("")</literal>) qui vaut <literal>0</literal> et la variable qui vaut aussi 0 et comme 0==0, la boucle ne commence même pas. </para> <para> La correction de ceci est simple : il suffit de remplacer les commandes while par: <informalexample> <programlisting role="php"><?php while ((string)$key != "") {?> </programlisting> </informalexample> </para> </sect1> <sect1 id="migration.errors"> <title>Les messages d'erreur ont changé</title> <simpara> 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é. </simpara> </sect1> <sect1 id="migration.booleval"> <title>Evaluation rapide des booléens </title> <simpara> En PHP 3., l'évaluation des est court-circuité. Cela signifie dans une expression telle que (<literal>(1 || test_me())</literal>), la fonction test_me() ne sera pas exécutée, car cela ne changera pas le résultat. </simpara> <simpara> C'est une amélioration mineure, mais qui peut avoir des effets secondaires importants. </simpara> </sect1> <sect1 id="migration.truefalse"> <title>La valeur &true;/&false; comme retour de fonctions</title> <simpara> 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. </simpara> <para> <example> <title> Migration depuis 2.0: valeur retournées, ancienne façon </title> <programlisting role="php"><?php $fp = fopen($file, "r"); if ($fp == -1); echo("Impossible d'ouvrir le fichier $file en lecture <br>\n"); endif;?> </programlisting> </example> <example> <title>Migration depuis 2.0: valeur retournées, nouvelle façon</title> <programlisting role="php"><?php $fp = @fopen($file, "r") or print("Impossible d'ouvrir le fichier $file en lecture<br>\n");?> </programlisting> </example> </para> </sect1> <sect1 id="migration.other"> <title>Diverses incompatibilités</title> <itemizedlist> <listitem> <simpara> 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. </simpara> </listitem> <listitem> <simpara> <function>echo</function> n'utilise plus de chaîne de formatage. Il faut utiliser <function>printf</function> à la place. </simpara> </listitem> <listitem> <simpara> En PHP/FI 2.0, un effet secondaire de l'implémentation faisait que <literal>$foo[0]</literal> était la même chose que <literal>$foo</literal>. Ce n'est plus vrai en PHP 3.0. </simpara> </listitem> <listitem> <simpara> Lire un tableau avec $array[] n'est plus valable. </simpara> <simpara> Ainsi, il n'est plus possible de passer en revue un tableau avec des boucles telles que <literal>$data = $array[]</literal>. Utilisez <function>current</function> et <function>next</function> à la place. </simpara> <simpara> Ainsi, <literal>$array1[] = $array2</literal> n'ajoute pas les valeurs de <literal>$array2</literal> à <literal>$array1</literal>, mais crée un nouvel élément dans <literal>$array1</literal> et y affecte <literal>$array2</literal> comme dernier élément. Voir aussi les tableaux multidimensionnels. </simpara> </listitem> <listitem> <simpara> <literal>"+"</literal> 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 <literal>"."</literal> à la place. </simpara> </listitem> </itemizedlist> <example> <title>Migration depuis 2.0: concaténation de chaînes</title> <programlisting role="php"><?php echo "1" + "1";?> </programlisting> <para> En PHP 2.0 cela retournerait 11, en PHP 3.0 cela va retourner 2. A la place, faites : <programlisting role="php"><?php echo "1"."1";?> </programlisting> <programlisting role="php"><?php $a = 1; $b = 1; echo $a + $b;?> </programlisting> </para> <para> Cela va afficher 2, tant en PHP 2.0 qu'en 3.0. <programlisting role="php"><?php $a = 1; $b = 1; echo $a.$b;?> </programlisting> Cela va afficher 11 en PHP 3.0. </para> </example> </sect1> </appendix><!-- Keep this comment at the end of the fileLocal variables:mode: sgmlsgml-omittag:tsgml-shorttag:tsgml-minimize-attributes:nilsgml-always-quote-attributes:tsgml-indent-step:1sgml-indent-data:tsgml-parent-document:nilsgml-default-dtd-file:"../manual.ced"sgml-exposed-tags:nilsgml-local-catalogs:nilsgml-local-ecat-files:nilEnd:--> \ No newline at end of file
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 @@ -<!-- $Revision: 1.6 $ --> - <appendix id="migration4"> - <title>Migration de PHP 3.0 à PHP 4.0</title> - <sect1 id="migration4.changes"> - <title>Ce qui a changé en PHP 4.0</title> - <para> - 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. - </para> - </sect1> - <sect1 id="migration4.parser"> - <title>Comportement de l'analyseur</title> - <para> - 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. - </para> - <para> - Une des nouvelles conditions introduites est que les fichiers - inclus et requis (<function>include</function> et - <function>require</function>) 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 <literal>for</literal> ou <literal>while</literal>, - une condition <literal>if</literal> ou un cas <literal>switch</literal> - dans un fichier, et finir la boucle ou placer les cas - <literal>else</literal>, <literal>endif</literal>, - <literal>case</literal> ou <literal>break</literal> - dans un autre fichier. - </para> - <para> - Il est toujours valable d'inclure du code supplémentaire depuis - une boucle ou dans une condition, mais les accolades de - bloc <literal>{...}</literal>, et les éléments de la boucle - doivent être dans le même fichier ou chaîne évaluée avec - <function>eval</function>. - </para> - <para> - Cela ne devrait pas perturber trop de monde, car étaler son - code de cette façon est plutôt un style à éviter. - </para> - <para> - Une autre nouveauté est qu'il est plus possible de faire - retourner une valeur avec un fichier requis (<function>require</function>) - (mais c'est plutôt rare en PHP 3.0). Retourner une valeur - avec un fichier inclus (<function>include</function>) est toujours - possible. - </para> - </sect1> - <sect1 id="migration4.errors"> - <title>Rapport d'erreur</title> - <sect2 id="migration4.error_reporting"> - <title>Changement de configuration</title> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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 <filename>php.ini</filename>: - <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>. - Si vous voulez supprimer en plus les alertes, vous pouvez - ajouter la constante appropriée, en la combinant avec l'opérateur - OU logique '|': - <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>. - </para> - <warning> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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. - </para> - </warning> - </sect2> - <sect2 id="migration4.messages"> - <title>Nouveaux messages d'erreurs</title> - <para> - 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. - </para> - <para> - 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 : - <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier - ce code en <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal> - rendra l'analyseur heureux, et améliorera grandement votre - style et la sécurité du code. - </para> - <para> - PHP 4.0 vous signalera les variables ou les - éléments de tableaux non initialisés. - </para> - </sect2> - </sect1> - <sect1 id="migration4.initializers"> - <title>Initialiseur</title> - <para> - 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. - </para> - <para> - 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. - </para> - </sect1> - <sect1 id="migration4.empty"> - <title><literal>empty("0")</literal></title> - <para> - L'évolution la plus polémique est celle de <function>empty</function>. - Une chaîne contenant seulement le caractère - <literal>'0'</literal> (zéro) est maintenant considérée comme - vide, alors qu'elle ne l'était pas en PHP 3.0. - </para> - <para> - 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. - </para> - </sect1> - <sect1 id="migration4.missing"> - <title>Fonctions manquantes</title> - <para> - 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. - </para> - <sect2 id="migration4.impossible"> - <title>Fonctions manquantes pour des raisons de structure</title> - <para> - 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 <filename>php.ini</filename>. - </para> - <para> - 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. - </para> - </sect2> - <sect2 id="migration4.deprecated"> - <title>Fonctions et extensions obsolètes</title> - <para> - Les extensions Adabas et Solid n'existent plus. Elles sont intégrées - dans les fonctions <link linkend="ref.odbc">ODBC Unifié</link>. - </para> - </sect2> - <sect2 id="migration4.unset"> - <title>Nouveau statut pour <function>unset</function></title> - <para> - <function>unset</function>, 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'. - </para> - <para> - Cela n'a pas de conséquence directe sur le comportement de - <function>unset</function>, mais utiliser cette fonction - pour faire un test avec <function>function_exists</function> - retournera <literal>FALSE</literal> comme il se doit avec - les fonction bas niveau comme <function>echo</function>. - </para> - <para> - Une autre application pratique disparue est qu'il n'est plus possible - d'appeler <function>unset</function> indirectement, c'est-à-dire que - <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus. - </para> - </sect2> - </sect1> - <sect1 id="migration4.extension"> - <title>Extensions PHP 3.0</title> - <para> - 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). - </para> - </sect1> - <sect1 id="migration4.substitution"> - <title>Substitution de variables dans les chaînes</title> - <para> - 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. - </para> - <para> - Pour cela, il suffit de placer la variable entre accolades, le signe - $ suivant immédiatement la première accolade : - <literal>{$variable['a']}</literal> - </para> - <para> - Pour utiliser la valeur d'un membre d'objet dans une chaîne, - il suffit d'écrire : <literal>"text {$obj->member} text"</literal>; - alors qu'en PHP 3.0, il fallait faire comme ceci : - <literal>"texte".$objet->membre." texte"</literal>. - </para> - <para> - 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 - <literal>{$</literal> dans votre code, et en les remplaçant par - <literal>\{$</literal> avec votre outil de remplacement habituel. - </para> - </sect1> - <sect1 id="migration4.cookies"> - <title>Cookies</title> - <para> - PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre - inverse de celui du code (l'ordre des appels à - <function>setcookie</function>). PHP 4.0 rétablit l'ordre naturel - en les envoyant dans le même ordre que vous même. - </para> - <para> - 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. - </para> - </sect1> - </appendix> -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-omittag:t -sgml-shorttag:t -sgml-minimize-attributes:nil -sgml-always-quote-attributes:t -sgml-indent-step:1 -sgml-indent-data:t -sgml-parent-document:nil -sgml-default-dtd-file:"../../manual.ced" -sgml-exposed-tags:nil -sgml-local-catalogs:nil -sgml-local-ecat-files:nil -End: ---> +<?xml encoding="iso-8859-1"?><!-- $Revision: 1.7 $ --> <appendix id="migration4"> <title>Migration de PHP 3.0 à PHP 4.0</title> <sect1 id="migration4.changes"> <title>Ce qui a changé en PHP 4.0</title> <para> 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. </para> </sect1> <sect1 id="migration4.php4.with.php3"> <title>Utiliser PHP 3 et PHP 4 simultanément</title> <simpara> 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. </simpara> <simpara> Ceci a été fait sur les plate-formes suivantes : </simpara> <itemizedlist> <listitem> <simpara> Linux avec les binutils récents (testé avec binutils 2.9.1.0.25) </simpara> </listitem> <listitem> <simpara> Solaris 2.5 ou plus récent </simpara> </listitem> <listitem> <simpara> FreeBSD (testé avec 3.2, 4.0) </simpara> </listitem> </itemizedlist> <para> Pour l'activer, configurez PHP 3 et PHP 4 pour qu'ils utilisent APXS (<link linkend="install.configure.with-apxs"><option role="configure">--with-apxs</option></link>) et les extensions nécessaires (<link linkend="install.configure.enable-versioning"><option role="configure">--enable-versioning</option></link>). En dehors de cela, toutes les instructions d'installation habituelles s'appliquent. Par exemple : <informalexample> <programlisting>$ ./configure \ --with-apxs=/apache/bin/apxs \ --enable-versioning \ --with-mysql \ --enable-track-vars </programlisting> </informalexample> </para> </sect1> <sect1 id="migration4.configuration"> <title>Migration des fichiers de configuration</title> <para> Le fichier de configuration global, <filename>php3.ini</filename>, a été renommé en <filename>php.ini</filename>. </para> <para> 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. <informalexample> <programlisting>application/x-httpd-php3 --> application/x-httpd-phpapplication/x-httpd-php3-source --> application/x-httpd-php-source </programlisting> </informalexample> </para> <para> 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 : <informalexample> <programlisting>AddType application/x-httpd-php3 .php3AddType application/x-httpd-php3-source .php3sAddType application/x-httpd-php .phpAddType application/x-httpd-php-source .phps </programlisting> </informalexample> </para> <simpara> De plus, les directives de nom de PHP pour Apache ont aussi été modifiées. </simpara> <para> Depuis PHP 4.0, il n'y a que 4 directives Apache qui se rapportent à PHP : <informalexample> <programlisting>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] </programlisting> </informalexample> </para> <simpara> Il y a deux différences entre les options Admin et les autres valeurs : </simpara> <itemizedlist> <listitem> <simpara> Les options Admin ne peuvent être placées que des le fichier de configuration général (i.e., httpd.conf). </simpara> </listitem> <listitem> <simpara> 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 <filename>.htaccess</filename>, cela annulerait toute la sécurité du safe mode. A l'inverse, les valeurs Admin peuvent modifier n'importe quelle directive PHP. </simpara> </listitem> </itemizedlist> <simpara> 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 <filename>.htaccess</filename> 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. </simpara> <para> Pour convertir votre fichier de configuration Apache, exécutez le script <filename>apconf-conv.sh</filename> (disponible dans le dossier <filename>scripts/apache/</filename>). Par exemple : <informalexample> <programlisting>~/php4/scripts/apache:# ./apconf-conv.sh /usr/local/apache/conf/httpd.conf </programlisting> </informalexample> </para> <simpara> Votre configuration originale sera sauvée dans le fichier <filename>httpd.conf.orig</filename>. </simpara> <para> Pour convertir vos fichiers <filename>.htaccess</filename>, exécutez le script <filename>aphtaccess-conv.sh</filename> (disponible dans le dossier <filename>scripts/apache/</filename>). Par exemple : <informalexample> <programlisting>~/php4/scripts/apache:# find / -name .htaccess -exec ./aphtaccess-conv.sh {} \; </programlisting> </informalexample> </para> <simpara> De la même façon, votre vieux fichier <filename>.htaccess</filename> sera sauvé sous le nom <filename>.htaccess.orig</filename>. </simpara> <simpara> Les scripts de conversion requièrent l'installation préalable de awk. </simpara> </sect1> <sect1 id="migration4.parser"> <title>Comportement de l'analyseur</title> <para> 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. </para> <para> Une des nouvelles conditions introduites est que les fichiers inclus et requis (<function>include</function> et <function>require</function>) 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 <literal>for</literal> ou <literal>while</literal>, une condition <literal>if</literal> ou un cas <literal>switch</literal> dans un fichier, et finir la boucle ou placer les cas <literal>else</literal>, <literal>endif</literal>, <literal>case</literal> ou <literal>break</literal> dans un autre fichier. </para> <para> Il est toujours valable d'inclure du code supplémentaire depuis une boucle ou dans une condition, mais les accolades de bloc <literal>{...}</literal>, et les éléments de la boucle doivent être dans le même fichier ou chaîne évaluée avec <function>eval</function>. </para> <para> Cela ne devrait pas perturber trop de monde, car étaler son code de cette façon est plutôt un style à éviter. </para> <para> Une autre nouveauté est qu'il est plus possible de faire retourner une valeur avec un fichier requis (<function>require</function>) (mais c'est plutôt rare en PHP 3.0). Retourner une valeur avec un fichier inclus (<function>include</function>) est toujours possible. </para> </sect1> <sect1 id="migration4.error-reporting"> <title>Rapport d'erreur</title> <sect2 id="migration4.error-reporting.config"> <title>Changement de configuration</title> <para> 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. </para> <para> 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. </para> <para> 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 <filename>php.ini</filename>: <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>. Si vous voulez supprimer en plus les alertes, vous pouvez ajouter la constante appropriée, en la combinant avec l'opérateur OU logique '|': <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>. </para> <warning> <para> 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. </para> <para> 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. </para> <para> 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. </para> </warning> </sect2> <sect2 id="migration4.error-reporting.additions"> <title>Nouveaux messages d'erreurs</title> <para> 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. </para> <para> 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 : <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier ce code en <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal> rendra l'analyseur heureux, et améliorera grandement votre style et la sécurité du code. </para> <para> PHP 4.0 vous signalera les variables ou les éléments de tableaux non initialisés. </para> </sect2> </sect1> <sect1 id="migration4.initializers"> <title>Initialiseur</title> <para> 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. </para> <para> 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. </para> </sect1> <sect1 id="migration4.empty"> <title><literal>empty("0")</literal></title> <para> L'évolution la plus polémique est celle de <function>empty</function>. Une chaîne contenant seulement le caractère <literal>'0'</literal> (zéro) est maintenant considérée comme vide, alors qu'elle ne l'était pas en PHP 3.0. </para> <para> 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. </para> </sect1> <sect1 id="migration4.missing"> <title>Fonctions manquantes</title> <para> 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. </para> <sect2 id="migration4.missing.concept"> <title>Fonctions manquantes pour des raisons de structure</title> <para> 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 <filename>php.ini</filename>. </para> <para> 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. </para> </sect2> <sect2 id="migration4.deprecate"> <title>Fonctions et extensions obsolètes</title> <para> Les extensions Adabas et Solid n'existent plus. Elles sont intégrées dans les fonctions <link linkend="ref.odbc">ODBC Unifié</link>. </para> </sect2> <sect2 id="migration4.unset"> <title>Nouveau statut pour <function>unset</function></title> <para> <function>unset</function>, 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'. </para> <para> Cela n'a pas de conséquence directe sur le comportement de <function>unset</function>, mais utiliser cette fonction pour faire un test avec <function>function_exists</function> retournera <literal>FALSE</literal> comme il se doit avec les fonction bas niveau comme <function>echo</function>. </para> <para> Une autre application pratique disparue est qu'il n'est plus possible d'appeler <function>unset</function> indirectement, c'est-à-dire que <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus. </para> </sect2> </sect1> <sect1 id="migration4.extensions"> <title>Extensions PHP 3.0</title> <para> 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). </para> </sect1> <sect1 id="migration4.string"> <title>Substitution de variables dans les chaînes</title> <para> 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. </para> <para> Pour cela, il suffit de placer la variable entre accolades, le signe $ suivant immédiatement la première accolade : <literal>{$variable['a']}</literal> </para> <para> Pour utiliser la valeur d'un membre d'objet dans une chaîne, il suffit d'écrire : <literal>"text {$obj->member} text"</literal>; alors qu'en PHP 3.0, il fallait faire comme ceci : <literal>"texte".$objet->membre." texte"</literal>. </para> <para> 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 <literal>{$</literal> dans votre code, et en les remplaçant par <literal>\{$</literal> avec votre outil de remplacement habituel. </para> </sect1> <sect1 id="migration4.cookies"> <title>Cookies</title> <para> PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre inverse de celui du code (l'ordre des appels à <function>setcookie</function>). PHP 4.0 rétablit l'ordre naturel en les envoyant dans le même ordre que vous même. </para> <para> 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. </para> </sect1> </appendix><!-- Keep this comment at the end of the fileLocal variables:mode: sgmlsgml-omittag:tsgml-shorttag:tsgml-minimize-attributes:nilsgml-always-quote-attributes:tsgml-indent-step:1sgml-indent-data:tsgml-parent-document:nilsgml-default-dtd-file:"../../manual.ced"sgml-exposed-tags:nilsgml-local-catalogs:nilsgml-local-ecat-files:nilEnd:--> \ 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 @@ -<!-- $Revision: 1.7 $ --> -<appendix id="migration"> - <title>Migration de PHP/FI 2.0 à PHP 3.0</title> - <sect1 id="migration-about"> - <title>A propos des incompatibilités en 3.0</title> - <simpara> - 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. - </simpara> - <simpara> - 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. - </simpara> - <simpara> - 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. - </simpara> - <simpara> - 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. - </simpara> - </sect1> - <sect1 id="migration-startendtags"> - <title>Balises PHP</title> - <para> - La première chose que vous remarquerez probablement est que les balises - de PHP start et end ont changé. L'ancienne forme - <literal><? ?></literal> a été remplacée par trois - nouvelles balises possibles : - <example> - <title>Migration: Migration: balises start/end </title> - <programlisting role="php"> -<?php - echo "Ceci est du code PHP/FI 2.0.\n";? -?> - </programlisting> - </example> - Comme en version 2.0, PHP/FI accepte aussi cette variante : - <example> - <title>Migration: premières nouvelles balises PHP</title> - <programlisting role="php"> -<?php - echo "Ceci est du code PHP 3.0!\n"; -?> - </programlisting> - </example> - 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 : - <example> - <title>Migration: Nouvelles balises PHP</title> - <programlisting role="php"> -<?php - echo "Ceci est du code PHP 3.0!\n"; -?> - </programlisting> - </example> - 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 : - <example><title>Nouvelles balises PHP</title> - <programlisting role="php"> -<script language="php"> - echo "Ceci est du code PHP 3.0!\n"; -</script> - </programlisting> - </example> - </para> - </sect1> - <sect1 id="migration-if-endif"> - <title>Syntaxe if..endif</title> - <para> - 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 : - <example> - <title>Migration: ancienne syntaxe if..endif </title> - <programlisting role="php"> -<?php - if ($foo); - echo "oui\n"; - elseif ($bar); - echo "presque\n"; - else; - echo "non\n"; - endif; -?> - </programlisting> - </example> - <example> - <title>Migration: nouvelle syntaxe if..endif</title> - <programlisting role="php"> -<?php - if ($foo): - echo "oui\n"; - elseif ($bar): - echo "presque\n"; - else: - echo "non\n"; - endif; -?> - </programlisting> - </example> - Notez que les points virgules ont été remplacée par des points dans - toutes les commandes, sauf pour la dernière expression (endif). - </para> - </sect1> - <sect1 id="migration-while"> - <title>Syntaxe while</title> - <para> - Tout comme pour if..endif, la syntaxe des boucles while..endwhile a changée : - <example> - <title>Migration: ancienne syntaxe while..endwhile </title> - <programlisting role="php"> -<?php - while ($more_to_come); - ... - endwhile; -?> - </programlisting> - </example> - <example><title>Migration: nouvelle syntaxe while..endwhile</title> - <programlisting role="php"> -<?php - while ($more_to_come): - ... - endwhile; -?> - </programlisting> - </example> - </para> - <warning> - <simpara> - Attention : si vous utilisez la vieille syntaxe while..endwhile en PHP 3.0, vous - obtiendrez une boucle sans fin ! - </simpara> - </warning> - </sect1> - <sect1 id="migration-expr"> - <title>Types d'expression</title> - <simpara> - 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. - </simpara> - <para> - Considérez les lignes suivantes: - <informalexample> - <programlisting role="php"> -<?php - $a[0]=5; - $a[1]=7; - $key = key($a); - while ("" != $key) { - echo "$keyn"; - next($a); - } -?> - </programlisting> - </informalexample> - 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, <literal>""</literal> n'est pas <literal>""</literal>, - 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 - (<literal>atoi("")</literal>) qui vaut <literal>0</literal> et la variable - qui vaut aussi 0 et comme 0==0, la boucle ne commence même pas. - </para> - <para> - La correction de ceci est simple : il suffit de remplacer les commandes while par: - <informalexample> - <programlisting role="php"> -<?php - while ((string)$key != "") { -?> - </programlisting> - </informalexample> - </para> - </sect1> - <sect1 id="migration-errors"> - <title>Les messages d'erreur ont changé</title> - <simpara> - 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é. - </simpara> - </sect1> - <sect1 id="migration-booleval"> - <title>Evaluation rapide des booléens </title> - <simpara> - En PHP 3., l'évaluation des est court-circuité. Cela signifie dans une - expression telle que (<literal>(1 || test_me())</literal>), la fonction test_me() - ne sera pas exécutée, car cela ne changera pas le résultat. - </simpara> - <simpara> - C'est une amélioration mineure, mais qui peut avoir des effets secondaires importants. - </simpara> - </sect1> - <sect1 id="migration-truefalse"> - <title>La valeur &true;/&false; comme retour de fonctions</title> - <simpara> - 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. - </simpara> - <para> - <example> - <title> - Migration depuis 2.0: valeur retournées, ancienne façon - </title> - <programlisting role="php"> -<?php - $fp = fopen($file, "r"); - if ($fp == -1); - echo("Impossible d'ouvrir le fichier $file en lecture <br>\n"); - endif; -?> - </programlisting> - </example> - <example> - <title>Migration depuis 2.0: valeur retournées, nouvelle façon</title> - <programlisting role="php"> -<?php - $fp = @fopen($file, "r") or - print("Impossible d'ouvrir le fichier $file en lecture<br>\n"); -?> - </programlisting> - </example> - </para> - </sect1> - <sect1 id="migration-other"> - <title>Diverses incompatibilités</title> - <itemizedlist> - <listitem> - <simpara> - 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. - </simpara> - </listitem> - <listitem> - <simpara> - <function>echo</function> n'utilise plus de chaîne de formatage. Il faut - utiliser <function>printf</function> à la place. - </simpara> - </listitem> - <listitem> - <simpara> - En PHP/FI 2.0, un effet secondaire de l'implémentation faisait que - <literal>$foo[0]</literal> était la même chose que - <literal>$foo</literal>. Ce n'est plus vrai en PHP 3.0. - </simpara> - </listitem> - <listitem> - <simpara> - Lire un tableau avec $array[] n'est plus valable. - </simpara> - <simpara> - Ainsi, il n'est plus possible de passer en revue un tableau avec des - boucles telles que <literal>$data = $array[]</literal>. Utilisez - <function>current</function> et <function>next</function> à la place. - </simpara> - <simpara> - Ainsi, <literal>$array1[] = $array2</literal> n'ajoute pas les valeurs - de <literal>$array2</literal> à <literal>$array1</literal>, - mais crée un nouvel élément dans <literal>$array1</literal> - et y affecte <literal>$array2</literal> comme dernier élément. - Voir aussi les tableaux multidimensionnels. - </simpara> - </listitem> - <listitem> - <simpara> - <literal>"+"</literal> 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 <literal>"."</literal> à la place. - </simpara> - </listitem> - </itemizedlist> - <example> - <title>Migration depuis 2.0: concaténation de chaînes</title> - <programlisting role="php"> -<?php - echo "1" + "1"; -?> - </programlisting> - <para> - En PHP 2.0 cela retournerait 11, en PHP 3.0 cela va retourner 2. A la place, - faites : - <programlisting role="php"> -<?php - echo "1"."1"; -?> - </programlisting> - <programlisting role="php"> -<?php - $a = 1; - $b = 1; - echo $a + $b; -?> - </programlisting> - </para> - <para> - Cela va afficher 2, tant en PHP 2.0 qu'en 3.0. - <programlisting role="php"> -<?php - $a = 1; - $b = 1; - echo $a.$b; -?> - </programlisting> - Cela va afficher 11 en PHP 3.0. - </para> - </example> - </sect1> - </appendix> -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-omittag:t -sgml-shorttag:t -sgml-minimize-attributes:nil -sgml-always-quote-attributes:t -sgml-indent-step:1 -sgml-indent-data:t -sgml-parent-document:nil -sgml-default-dtd-file:"../manual.ced" -sgml-exposed-tags:nil -sgml-local-catalogs:nil -sgml-local-ecat-files:nil -End: ---> +<?xml encoding="iso-8859-1"?><!-- $Revision: 1.8 $ --><appendix id="migration"> <title>Migration de PHP/FI 2.0 à PHP 3.0</title> <sect1 id="migration.about"> <title>A propos des incompatibilités en 3.0</title> <simpara> 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. </simpara> <simpara> 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. </simpara> <simpara> 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. </simpara> <simpara> 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. </simpara> </sect1> <sect1 id="migration.startendtags"> <title>Balises PHP</title> <para> La première chose que vous remarquerez probablement est que les balises de PHP start et end ont changé. L'ancienne forme <literal><? ?></literal> a été remplacée par trois nouvelles balises possibles : <example> <title>Migration: Migration: balises start/end </title> <programlisting role="php"><?php echo "Ceci est du code PHP/FI 2.0.\n";??> </programlisting> </example> Comme en version 2.0, PHP/FI accepte aussi cette variante : <example> <title>Migration: premières nouvelles balises PHP</title> <programlisting role="php"><?php echo "Ceci est du code PHP 3.0!\n";?> </programlisting> </example> 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 : <example> <title>Migration: Nouvelles balises PHP</title> <programlisting role="php"><?php echo "Ceci est du code PHP 3.0!\n";?> </programlisting> </example> 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 : <example><title>Nouvelles balises PHP</title> <programlisting role="php"><script language="php"> echo "Ceci est du code PHP 3.0!\n";</script> </programlisting> </example> </para> </sect1> <sect1 id="migration.if-endif"> <title>Syntaxe if..endif</title> <para> 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 : <example> <title>Migration: ancienne syntaxe if..endif </title> <programlisting role="php"><?php if ($foo); echo "oui\n"; elseif ($bar); echo "presque\n"; else; echo "non\n"; endif;?> </programlisting> </example> <example> <title>Migration: nouvelle syntaxe if..endif</title> <programlisting role="php"><?php if ($foo): echo "oui\n"; elseif ($bar): echo "presque\n"; else: echo "non\n"; endif;?> </programlisting> </example> Notez que les points virgules ont été remplacée par des points dans toutes les commandes, sauf pour la dernière expression (endif). </para> </sect1> <sect1 id="migration.while"> <title>Syntaxe while</title> <para> Tout comme pour if..endif, la syntaxe des boucles while..endwhile a changée : <example> <title>Migration: ancienne syntaxe while..endwhile </title> <programlisting role="php"><?php while ($more_to_come); ... endwhile;?> </programlisting> </example> <example><title>Migration: nouvelle syntaxe while..endwhile</title> <programlisting role="php"><?php while ($more_to_come): ... endwhile;?> </programlisting> </example> </para> <warning> <simpara> Attention : si vous utilisez la vieille syntaxe while..endwhile en PHP 3.0, vous obtiendrez une boucle sans fin ! </simpara> </warning> </sect1> <sect1 id="migration.expr"> <title>Types d'expression</title> <simpara> 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. </simpara> <para> Considérez les lignes suivantes: <informalexample> <programlisting role="php"><?php $a[0]=5; $a[1]=7; $key = key($a); while ("" != $key) { echo "$keyn"; next($a); }?> </programlisting> </informalexample> 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, <literal>""</literal> n'est pas <literal>""</literal>, 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 (<literal>atoi("")</literal>) qui vaut <literal>0</literal> et la variable qui vaut aussi 0 et comme 0==0, la boucle ne commence même pas. </para> <para> La correction de ceci est simple : il suffit de remplacer les commandes while par: <informalexample> <programlisting role="php"><?php while ((string)$key != "") {?> </programlisting> </informalexample> </para> </sect1> <sect1 id="migration.errors"> <title>Les messages d'erreur ont changé</title> <simpara> 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é. </simpara> </sect1> <sect1 id="migration.booleval"> <title>Evaluation rapide des booléens </title> <simpara> En PHP 3., l'évaluation des est court-circuité. Cela signifie dans une expression telle que (<literal>(1 || test_me())</literal>), la fonction test_me() ne sera pas exécutée, car cela ne changera pas le résultat. </simpara> <simpara> C'est une amélioration mineure, mais qui peut avoir des effets secondaires importants. </simpara> </sect1> <sect1 id="migration.truefalse"> <title>La valeur &true;/&false; comme retour de fonctions</title> <simpara> 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. </simpara> <para> <example> <title> Migration depuis 2.0: valeur retournées, ancienne façon </title> <programlisting role="php"><?php $fp = fopen($file, "r"); if ($fp == -1); echo("Impossible d'ouvrir le fichier $file en lecture <br>\n"); endif;?> </programlisting> </example> <example> <title>Migration depuis 2.0: valeur retournées, nouvelle façon</title> <programlisting role="php"><?php $fp = @fopen($file, "r") or print("Impossible d'ouvrir le fichier $file en lecture<br>\n");?> </programlisting> </example> </para> </sect1> <sect1 id="migration.other"> <title>Diverses incompatibilités</title> <itemizedlist> <listitem> <simpara> 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. </simpara> </listitem> <listitem> <simpara> <function>echo</function> n'utilise plus de chaîne de formatage. Il faut utiliser <function>printf</function> à la place. </simpara> </listitem> <listitem> <simpara> En PHP/FI 2.0, un effet secondaire de l'implémentation faisait que <literal>$foo[0]</literal> était la même chose que <literal>$foo</literal>. Ce n'est plus vrai en PHP 3.0. </simpara> </listitem> <listitem> <simpara> Lire un tableau avec $array[] n'est plus valable. </simpara> <simpara> Ainsi, il n'est plus possible de passer en revue un tableau avec des boucles telles que <literal>$data = $array[]</literal>. Utilisez <function>current</function> et <function>next</function> à la place. </simpara> <simpara> Ainsi, <literal>$array1[] = $array2</literal> n'ajoute pas les valeurs de <literal>$array2</literal> à <literal>$array1</literal>, mais crée un nouvel élément dans <literal>$array1</literal> et y affecte <literal>$array2</literal> comme dernier élément. Voir aussi les tableaux multidimensionnels. </simpara> </listitem> <listitem> <simpara> <literal>"+"</literal> 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 <literal>"."</literal> à la place. </simpara> </listitem> </itemizedlist> <example> <title>Migration depuis 2.0: concaténation de chaînes</title> <programlisting role="php"><?php echo "1" + "1";?> </programlisting> <para> En PHP 2.0 cela retournerait 11, en PHP 3.0 cela va retourner 2. A la place, faites : <programlisting role="php"><?php echo "1"."1";?> </programlisting> <programlisting role="php"><?php $a = 1; $b = 1; echo $a + $b;?> </programlisting> </para> <para> Cela va afficher 2, tant en PHP 2.0 qu'en 3.0. <programlisting role="php"><?php $a = 1; $b = 1; echo $a.$b;?> </programlisting> Cela va afficher 11 en PHP 3.0. </para> </example> </sect1> </appendix><!-- Keep this comment at the end of the fileLocal variables:mode: sgmlsgml-omittag:tsgml-shorttag:tsgml-minimize-attributes:nilsgml-always-quote-attributes:tsgml-indent-step:1sgml-indent-data:tsgml-parent-document:nilsgml-default-dtd-file:"../manual.ced"sgml-exposed-tags:nilsgml-local-catalogs:nilsgml-local-ecat-files:nilEnd:--> \ No newline at end of file