PHP 5 : dernière RC avant finale

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes : aucune
0
10
juin
2004
PHP
L'AFUP relaie l'information du PHPGroup comme quoi la troisième « release candidate » de PHP5 est sortie.

Grossomodo entre le 25 Avril (RC2) et ce 9 juin (RC3) l'équipe de développement a corrigé beaucoup de bugs, traqué les fuites de mémoires, etc. Andi Gutmans (qui est le responsable des publications (NdM : release master) sur cette version) a appelé toutes les personnes maintenant des extensions à migrer vers le nouveau modèle. Dans la foulée Rainer Schaaf qui maintient le wrapper de la PDFlib a publié une nouvelle version qui a été (toujours dans la foulée) migrée vers PECL (qui est la bibliothèque des extensions PHP).

Cette « release candidate » est appelée à être la dernière et donc son niveau de qualité est censé être bon.

Ceux qui sont sous Ms Windows (...) peuvent télécharger Wamp Server qui est un installeur pour PHP5 RC3 (Wamp pour Win / Apache / MySQL / PHP).

Ceux qui veulent tous les détails peuvent regarder le changelog.

Enfin il est important de noter que contrairement à ce que l'on pourrait penser PHP5 sera plus rapide que PHP4. Ceci car de nombreux pans du moteur ont été revus. Vous pouvez utiliser l'outil de benchmark développé par Sebastien Bergmann pour avoir les performances de PHP5 RC3 ou aller sur le site de toutphp pour consulter la comparaison entre PHP5RC2 et PHP4.3.3.

Aller plus loin

  • # Je confirme

    Posté par  . Évalué à 5.

    Il a l'air d'être plus réactif que la première RC (pas testé la RC2 faute de temps) et effectivement moins sujet aux soubresauts...
    Comme je le disais dans ce journal https://linuxfr.org/~xsnipe/13575.html(...) Vivement l'intégration avec les objets Java (oui je sais pas pour tout de suite)

    • [^] # Re: Je confirme

      Posté par  (site web personnel) . Évalué à 5.

      Pour l'interfacage PHP/Java j'ai discutté avec les mecs de Zend lors de PHPQuebec et ils m'ont dit que ca marchait déja pour PHP5 et que ca devrait sortir un peu apres PHP5.0.
      Mais le seul hic c'est qu'a part ces qq infos glanées à un gars de Zend j'arrive pas a trouver un seul type qui soit au courant ...
      A suivre donc mais ca devrait être sympa. Surtout que maintenant on pourra sauvegarder des contextes aplicatifs.

      ++

      cyruss

      • [^] # Re: Je confirme

        Posté par  . Évalué à 0.

        Oui mais est-ce confirmé de l'autre côté ?? (Avec Sun) Je me demande si ça arrivera si rapidement... On verra mais c'est plus qu'utile, cela va presque de soit (enfin AMHA)...

        • [^] # Re: Je confirme

          Posté par  (site web personnel) . Évalué à 2.

          Des déclarations ont été faites en commun avec Sun, donc c'est officiel de ce coté là aussi.
          Si j'ai bien compris Sun doit faire au moins une implémentation tout ce qu'il propose comme spec pour Java, pour prouver que ça marche. Et PHP a été retenu pour ces exemples dans tout ce qui est liaison de Java avec d'autres langages de script.

          Perso je ne vois rien venir, la seule chose nouvelle c'est au contraire qu'ils ont cassé la liaison avec Java (possibilité d'utiliser des objets java) qui existait avec PHP4

      • [^] # Re: Je confirme

        Posté par  (site web personnel) . Évalué à 1.

        sauvegarder des contextes aplicatifs ??
        C'est quoi ? ca a l'air intéresant ...

        • [^] # Re: Je confirme

          Posté par  (site web personnel) . Évalué à 4.

          Le terme fait un peu pompeux mais avec les objets tu auras les methodes _sleep() et _wake() ce qui te permettra de conserver des données plus complexes que des simples chaines de caractères.

          Donc via sleep/wake et les sessions tu pourras garder des objets DOM, des connexions réseau ou des fichiers .au travers de tes différentes pages. Ca permet de limiter les pbms dus au mode client serveur pour la réalisation d'applications poussées.



          <mode grosse pub éhontée ;)>
          Plus d'infos dans le livre PHP5 avancé ;) aux editions Eyrolles à partir du 20
          </mode grosse pub éhontée ;)>

  • # Quelle version de PHP pour XML ?

    Posté par  . Évalué à 5.

    Je profite de cette brève pour poser une question à la communauté Linuxfr.

    Je travaille actuellement sur un projet d'édition électronique. Je souhaite utiliser XML avec DOM car ces deux technologies répondent tout à fait à mes besoins.

    L'application sera hébergée sur un serveur LAMP.

    Pour l'instant le serveur propose PHP4. Or la doc de PHP4 indique que les fonctions pour manipuler DOM sont expérimentales et peuvent être révoquées à tout moment.

    Vaut-il mieux utiliser PHP4 (si oui avec quelle API pour manipuler le DOM ?) ou attendre PHP5 sachant que le projet ne sera mis en production qu'au début de l'année 2005 ?

    Merci d'avance pour vos conseils.

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Quelle version de PHP pour XML ?

      Posté par  . Évalué à 1.

      Moinssez-moi si je me gourre mais je pense, si tu peux attendre, de voir avec la version 5 quand ce sera bien établi et tout et tout...

    • [^] # Re: Quelle version de PHP pour XML ?

      Posté par  (site web personnel) . Évalué à 4.

      > Vaut-il mieux utiliser PHP4

      Clairement pas. Leurs méthodes sont proprio, pas toujours finies, et il reste des memleak ou bugs qui ne seront pas corrigés.
      Par contre si tu te reposes dessus tu peux être sûr que ça ne changera plus, contrairement à ce qui est indiqué dans la doc.

      > attendre PHP5 sachant que le projet ne sera mis en production
      > qu'au début de l'année 2005 ?

      Pas besoin d'attendre alors, les RC sont déjà suffisament stables pour être utilisées lors des développements. Même avec de gros retards ça sera prêt en 2005.
      Le DOM de PHP5 vise la conformité aux spécifications du W3C donc tant que tu n'utilise que des choses qui sont prévues par ces specs, tu ne prend aucun risques vis à vis des possibles évolutions de PHP par la suite.

      Perso je te conseille très fortement d'utiliser le DOM de PHP5. Tu peux t'y plonger dès maintenant, l'essentiel est déjà implémenté et fonctionnel (plus que ce qui était fait en PHP4 de toutes façons).
      Par contre .. hum ... évites SimpleXML

      • [^] # Re: Quelle version de PHP pour XML ?

        Posté par  . Évalué à 1.

        Par contre .. hum ... évites SimpleXML
        Ah bon !! Pourquoi donc ?? Des arguments ??
        C'est vrai, je l'ai très peu utilisé mais ça me paraissait tellement simple...

        • [^] # Re: Quelle version de PHP pour XML ?

          Posté par  . Évalué à 5.

          Oui : trop simple, les fonctionnalités sont du même coup très limitées.

          un cas pratique de ce que SimpleXML ne peut pas faire : dans un code comme celui-ci (remplace les [ ] par les chevrons ) :

          [h1]Sortie de [a href="..."]php5[/a] en [abbr]RC3[/abbr][/h1]

          simplexml ne te permet pas de sortir la phrase "Sortie de php5 en RC3" : tu pourras par contre disposer de "Sortie de en", "php5" et "RC3" dans les variables correspondantes, mais pas moyen de reconstituer le texte dans l'ordre.

          Reste que simplexml peut rendre service pour des documents XML orientés données très structurés (fichiers de conf par exemple), mais pas pour du XHTML par exemple.

          • [^] # Re: Quelle version de PHP pour XML ?

            Posté par  . Évalué à 1.

            Ah oki, j'avais pas poussé les tests à ce point, effectivement ça mériterait d'être amélioré...

          • [^] # Re: Quelle version de PHP pour XML ?

            Posté par  (site web personnel) . Évalué à 2.

            Pire, SimpleXML ne sait pas faire la différence entre un commentaire et un élément :

            [hr] est strictement équivalent à [!-- hr --] une fois accédé par SimpleXML

            Reste le problème des espaces de noms qu'ont ne peux utiliser que via des requêtes xpath, des problèmes sur les attributs, de la dualité élément / liste d'élément, de la façon de récupérer le contenu des éléments ...

            Bref, c'est utile pour quelques trucs simples vite faits bien faits, mais loin d'être aussi bien qu'on le dit.

    • [^] # Re: Quelle version de PHP pour XML ?

      Posté par  (site web personnel) . Évalué à 3.

      Si tu ne veux pas attendre, il existe le framework PEAR pour faire ce que tu veux: http://pear.php.net/(...) .
      Très facile à installer, tu installes juste le core, et ensuite un outil en ligne de commande te permet d'installer des packages supplémentaires pour tes besoins spécifiques. Je n'ai pas encore essayé la manipulation de XML par PHP5, donc je peux pas te comparer les 2 approches à l'usage, mais si tu ne veux pas attendre la sortie de PHP5, c'est cela qu'il te faut.

  • # PHP5 fait exception.

    Posté par  . Évalué à 3.

    Trés mauvais jeu de mot pour dire que j'ai été trés surpris de voir que les erreurs php sont séparées du système d'exceptions mis en place dans le PHP5 : pas de possiblité d'attraper un fopen('nexistepas') dans un try catch (à part utiliser un user error handler qui lui lancerai une exceptions : beurk). Si il y en a parmis vous qui peuvent m'expliquer ce choix, ca m'interesserait.

    • [^] # Re: PHP5 fait exception.

      Posté par  . Évalué à -1.

      C'est vrai que ce n'est pas très propre. Cela montre que php5 n'est pas encore un language réellement objet même s'il supporte l'utilisation de ceux ci.

      Je pense que c'est réalisé comme ça car php est un language de script qui peu être utilisé à la mode php4. L'utilisation d'exceptions n'est donc pas systématique et la compatibilité avec les anciens sites est préservée. Dommage...

      • [^] # Re: PHP5 fait exception.

        Posté par  . Évalué à 3.

        Un langage orienté objet n'implique pas l'utilisation d'un système d'exceptions. Ici c'est uniquement une éventuelle question de cohérence.

    • [^] # Re: PHP5 fait exception.

      Posté par  (site web personnel) . Évalué à 2.

      Toutes les nouveautés sont faites pour êtres "facultatives". En gros si tu n'utilise aucune nouvelle extension objet rien ne renverra d'exception.
      Il est vrai qu'il est globalement plus simple de tester la valeur de retour que de tout mettre en try/catch dès que tu utilises une fonction. PHP privilégiant la simplicité sur les procédures "académiques" ...

      Ceci dit il y a eu il n'y a pas longtemps des discussions pour refaire la gestion d'erreur PHP : attribuer un type d'erreur (pas seulement un niveau) à chaque événément. Après tu peux déclarer ce que tu veux gérer en exception ou en erreur classique. Ça ne sera pas pour la 5.0 mais dans un futur à long terme je pense bien qu'on arrivera à un tel système (parce que l'état actuel est plutot batard, on est d'accord).

      Pour le moment tu peux toujours faire un gestionnaire d'erreur standard qui lit le message d'erreur PHP, remarque que c'est un fopen() qui plante et lance une exception. Ça relève du hack mais ça marche.

    • [^] # si si on peut traper les exceptions du systèmes : désolé ;)

      Posté par  . Évalué à 0.

      $old_error_handler = set_error_handler("myErrorHandler");

      function myErrorHandler($errno, $errstr, $errfile, $errline) {
      throw new Exception($errstr,$errno);
      }

      et donc ton fopen ...

      • [^] # Re: si si on peut traper les exceptions du systèmes : désolé ;)

        Posté par  . Évalué à 1.

        Relis mon post.

        • [^] # Autant pour moi

          Posté par  . Évalué à 0.

          Dans tous les cas, php n'est pas un langage objet à proprement parlé.
          C'est un très bonne intermédiaire entre ASP/VBScript et Java/ASP.NET.
          Il lui manque des notions essentielles comme la persistence des objets et des connexions aux bases de données.
          ==> en tout cas pas de base.

          D'où la nécessité d'utiliser un tas de composants en entête dans toutes les pages.

          • [^] # Re: Autant pour moi

            Posté par  (site web personnel) . Évalué à 3.

            Les connexions aux BDD persistent (enfin si tu ne marches pas en CGI qui arrête le processus à chaque page), ça depuis pas mal de temps (les fonctions *_pconnect())

            Tu peux sauvegarder tes objets en les sérialisant (sur le disque, en mémoire, peu importe). C'est clair que c'est moins élégant que ce qui existe en java (surtout parce qu'on recharge toutes les définitions de classe à chaque fois) mais ce n'est pas trop le problème.
            Ce qui fait la différence dans java ce sont plutot les mécanismes de synchro, de transaction, les objets partagés ... maintenant, est ce que
            c'est forcément quelque chose de nécessaire pour 80% des applis ?

            > Dans tous les cas, php n'est pas un langage objet à proprement parlé.
            > Il lui manque des notions essentielles [..]

            Ce qui me gêne c'est que les notions essentielles dont tu parles n'ont rien de nécessaires pour un langage objet, d'ailleurs la persistance n'a rien de spécifique à la POO non plus.
            PHP n'est pas java, on le sait, mais mis à part ça ...

  • # Licence ?

    Posté par  (site web personnel) . Évalué à 2.

    A la sortie de la version 4, j'ai entendu beaucoup de mal concernant la licence du language. Au point que la FSF demandait de rester sur la version 3. Est-ce que cela a changé ?

    • [^] # Re: Licence ?

      Posté par  (site web personnel) . Évalué à 4.

      Oui et non. Le problème ne venait pas de la licence de PHP mais de la licence du composant principal utilisé : le moteur Zend. Il était modifiable, distribuable mais il y avait un truc qui la rendait non libre.

      Ces problèmes ont été résolus il y a pas mal de temps. PHP et ZendEngine ont maintenant des licences tout à fait libres (et reconnues comme telles). Par contre elles ne sont pas compatibles GPL (et ça n'arrivera probablement jamais vu la mauvaise opinion de la GPL qu'on les développeurs PHP)

      La non compatibilité GPL est d'ailleurs la source d'un événement majeur avec PHP5 : la librairie cliente MySQL (je parle bien de la lib, pas de l'extension PHP) ne sera plus fournie par défaut comme ça avait toujours été le cas, et du coup ne sera plus compilée par défaut. Mysql AB a en effet rompu la compatibilité de la lib client entre Mysql 4.1 et 3.x, la nouvelle est sous GPL, donc non compatible avec la licence PHP. (ça a été résolu depuis avec une exception dans la licence de la lib cliente mysql mais je doute que la team PHP revienne jamais en arrière concernant son intégration dans la release PHP)

  • # Petite erreur d'orthographe

    Posté par  . Évalué à 2.

    Au risque de paraître un peu lourd, "sensé" s'orthographie "censé".
    Je faisais aussi la faute avant. En fait, je pensais que le mot avait la même racine que "sens" (le sens..). Mais d'après ma copine ça aurait plutôt un rapport avec "censure" (me souviens pas de l'explication exacte mais si ca tente qq'un je lui redemanderais ^^)

    • [^] # Précision du Robert

      Posté par  . Évalué à 1.

      sensé, ée [sSse] adj.

      • 1580; de 1. sens

      ¨ Qui a du bon sens. ? raisonnable, sage. « Aucun homme sensé n'aura l'idée saugrenue [º] » (Bernanos).
      à (Choses) Conforme à la raison. ? judicieux, rationnel. « Observations justes et sensées » (Sainte-Beuve).

      - CONTR. Absurde, déraisonnable, insensé.

      - HOM. Censé.

      -----------------------------------------------------

      censé, ée [sSse] adj.

      • 1611; p. p. de censer « censurer, réformer »; lat. censere « estimer, juger »

      ¨ Qui est supposé, réputé (suivi d'un v. à l'inf.). ? présumé. Il est censé être à Paris. Elle n'est pas censée le savoir. Nul n'est censé ignorer la loi.

      - HOM. Sensé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.