Sortie PHP 5.1.0

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
0
25
nov.
2005
PHP
La version 5.1.0 de PHP est sortie le 23 novembre. Après la mini révolution de la version 5.0 sortie il y a presque un an et demi, cette version apporte une nouvelle fois de nouvelles fonctionnalités importantes.

Outre les habituelles corrections de bugs (environ 400 !), les nouveautés du moteur Zend2 devrait permettre d'obtenir encore de meilleures performances grâce entre autre à une gestion plus fine de la mémoire. Le ChangeLog nous apprend aussi que beaucoup de modules ont été mis à jour dont MySQLi, PostgreSQL, le module de manipulation des tableaux, SOAP ou encore SPL (Standard PHP Library).

Autre grosse nouveauté de PHP 5.1 est (enfin!) l'introduction d'une nouvelle interface objet appelée PDO (PHP Data Object) permettant d'accéder de manière unifiée aux systèmes de bases de données les plus utilisés avec PHP (MySQL, PostgreSQL, SQLServer, Firebird, Sybase, SQLite, DB2, ODBC) sans avoir à passer par des classes d'abstraction écrites en PHP tel que PearDB ou AdoDB.

Mise à jour : Une version 5.1.1 est déjà disponible. Pas de grandes nouveautés à part quelques correctifs d'anomalies et de régressions, ainsi que la suppression de la classe native Date pour ne pas rentrer en conflit avec le paquet PEAR du même nom. Il est fortement recommandé de migrer rapidement en 5.1.1. Merci à J.Smith pour l'information PHP est un langage interprété créé en 1994 par Rasmus Lerdörf. Il s'agissait à l'origine d'une collection de fonctions écrites en Perl pour savoir qui venait visiter son CV. Au fur et à mesure, Rasmus Lerdörf se mit à écrire le premier vrai moteur PHP en langage C qu'il publia en 1995 sous le nom PHP/FI. À l'époque PHP/FI signifiait Personal Homepage Page/Form Interpreter. Sous l'impulsion d'Andi Gutmans et Zeev Suraski, le moteur fut réécrit et publié en 1997 sous le nom PHP3 signifiant PHP Hypertext Preprocessor. PHP4 est sorti en 2000 suivi par PHP5 l'année dernière qui apporta un grand nombre de nouveautés telles qu'une nouvelle orientation résolument objet ou le support simplifié et amélioré des technologies XML. Alors que cette version vient de sortir, PHP6 est déjà sur les rails avec de nombreuses nouveautés.
On estime qu'un tiers des sites Internet utilise PHP dans le monde et que 46% des sites français l'utiliserait (Source : Livre blanc de l'AFUP).

Aller plus loin

  • # Bonne et mauvaise nouvelle

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

    L'intégration de PDO est une bonne et une mauvaise nouvelle à la fois.

    Une bonne nouvelle car on a enfin une interface unifiée d'accès au SGBD intégrée dans PHP.

    Une mauvaise car PDO est loin d'être complet et quasiment inutilisable dans des projets conséquents, c'est dommage que ce soit PDO qui ait été retenu alors qu'il y avait pléthore de projets bien lus avancés.

    • [^] # Re: Bonne et mauvaise nouvelle

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

      Tu peux détailler un peu ce qu'apportaient les autres projets plus avancés ?
      J'ai beaucoup aimé la présentation de PDO au forum PHP 2005 alors s'il y a mieux ça m'intéresse :-)

      • [^] # Re: Bonne et mauvaise nouvelle

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

        On a tout d'abord ADODB-ext., dbx, DBDO ( qui fait du mapping OR en plus )

        Avec PDO, on a très peu d'accès au meta données, ce qui oblige à les récupérer d'une autre façon ( façon qui est souvent dépendante du SGBD, on perd donc l'abstraction )

        Les objets retournés avec PDO sont des objet standards ( comme avec mysql_fetch_object ), ça ne fait pas vraiment avancer le schmilblik en terme de programmation objet.

        Un binding avec libgda ( gnome-db ) aurait été à mon avis plus opportun.

        Maintenant, ça reste quand même une bonne chose qu'on ait une interface intégrée et objet de surcroit pour l'accès aux SGBD.

        • [^] # Re: Bonne et mauvaise nouvelle

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

          faudrait voir aussi niveau performance qui s'en sort le mieux

          Si PDO ne fait pas grand chose il a peut etre l'avantage d'etre rapide tout en apportant une certaine abstraction. Mais bon ça reste a voir on va attendre quelques benchmarks

        • [^] # Re: Bonne et mauvaise nouvelle

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

          > On a tout d'abord ADODB-ext., dbx, DBDO ( qui fait du mapping OR en plus )

          Les buts d'ADODB ou DBDO ne sont pas les mêmes.
          - ADODB est une abstraction de base de données
          - DBDO est un mapping objet-relationel
          - PDO est une API unifiée

          On ne demande pas à PDO de pouvoir avoir une instruction unique pour mysql et oracle (le but d'adodb), on lui demande juste que l'instruction soit à passer de la même façon.
          Ne pas être aller plus loin pour fournir un minimum d'abstraction est à mon avis une erreur mais c'est un choix qui se défend tout à fait.


          > Un binding avec libgda ( gnome-db ) aurait été à mon avis plus opportun.

          Là dessus on est d'accord. Il me semble que quelqu'un a commencé à travailler la dessus. Par contre j'ai cru comprendre que ça ne deviendrai jamais une solution poussée par PHP à cause du nombre de dépendances et de leur portage sur tous les systèmes où tourne PHP.

  • # Interprété ou compilé ?

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

    Les nouveautés du moteur Zend2 devrait permettre d'obtenir encore de meilleures performances grâce entre autre à une gestion plus fine de la mémoire.

    Question simple : Le moteur Zend2 compile t-il le code PHP pour de meilleurs performances et sinon pourquoi ne le fait-il pas ?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Interprété ou compilé ?

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

      Comme dans presque tous les langages de script actuel, PHP est compilé pour tourné dans une sorte de machine virtuelle.

      Par contre, le script doit être recompilé à chaque exécution à moins d'utiliser un cache d'op-code ( le code produit par la compilation ).

      • [^] # Re: Interprété ou compilé ?

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        et pour répondre à la question qui ne saurait tarder, "mais pourquoi ils n'incluent pas un cache d'opcode ?"

        - parce que la société Zend, qui est à l'origine du moteur, vend ce système de cache d'op-code (non libre), c'est pourquoi elle ne l'a pas inclus directement dans zend (ba oui, faut bien qu'ils bouffent les developpeurs de zend ;-) ). Du coup, il y a eu d'autres projets de système de cache qui ont été crée, libres.
        - il y en aura un fourni nativement dans PHP6 normalement.

        • [^] # Re: Interprété ou compilé ?

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

          Le Zned Optimizer n'est certe toujours pas libre, mais par contre, maintenant il est gratuit :
          http://zend.com/store/products/zend-optimizer.php

          • [^] # Re: Interprété ou compilé ?

            Posté par  . Évalué à 5.

            Oui, mais ca n'est pas nouveau, c'est forcement gratuit, car il permet de décoder les scripts encodés avec les autres softs Zend.

            Le produit le plus utile (et couteux) est la Zend Platform (avant: Zend Accelerator). Et en moins couteux, il y a eAccelerator qui fonctionne très bien ( http://www.eaccelerator.net/ )

            • [^] # Re: Interprété ou compilé ?

              Posté par  . Évalué à 1.

              Et en moins couteux, il y a eAccelerator qui fonctionne très bien ( http://www.eaccelerator.net/ )


              Merci pour l'URL. Le pire, c'est que ça marche ce truc.

              • [^] # Re: Interprété ou compilé ?

                Posté par  . Évalué à 2.

                Oui, je l'utilise en production sur pas mal de serveurs (php 4.x). Par contre le dev se limite actuellement à des bugfixes, vu que le créateur de projet (sous le nom de mmcache) s'est fait "récupèrer" par Zend et ne bosse plus que pour eux :-/.

          • [^] # Re: Interprété ou compilé ?

            Posté par  . Évalué à 1.

            Il est tres probable que l'opcode cache APC va etre livre avec PHP6, mais l'activation ne sera pas automatique (lors de l'installation).

            ps: desole pour les accents, pas de clavier francais...

        • [^] # Re: Interprété ou compilé ?

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

          C'est bien, bientôt PHP aura les foncitonnalités de Zope.

          • [^] # Re: Interprété ou compilé ?

            Posté par  . Évalué à -3.

            Alors il faut qu'il se dépêche, car la sortie de Zope 3.0 va sûrement faire du bruit...
            Exaspéré par les performances de J2EE et les carences de PHP dès qu'il faut développer des applications complexes (ou alors il faut piocher dans une multitude de librairies plus ou moins abouties), je fais partie de ceux qui pensent que Zope a les atouts pour mettre tout le monde d'accord.
            Il suffit de quelques minutes d'utilisation pour constater qu'une application sous Zope va vite, vraiment vite...

            • [^] # Re: Interprété ou compilé ?

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

              mmm je suis toujours impréssionné par ce genre de commentaires, nous développons des applications J2EE depuis un certain temps déja et on a jamais eu de problèmes de performances, on développe vite, bien et les perfs sont largement au RDV.
              Et quand à Zope, je n'ai pas vraimetn vu l'équivalent des choses que j'aime dans Java/J2EE (JSF, Hibernate, Spring, Eclipse, JMS, JDBC...)

              http://about.me/straumat

              • [^] # Re: Interprété ou compilé ?

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

                Que l'on utilise zope ou java il faut juste prévoir une machine avec beaucoup plus de ressources (mémoire notament)

                p.s: Et mince j'ai marché dedans. Je suis déjà dehors.

                • [^] # Re: Interprété ou compilé ?

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

                  Pas plus que php :)
                  J'oublais JTA qui est une des choses que j'adore chez J2EE :)

                  http://about.me/straumat

                  • [^] # Re: Interprété ou compilé ?

                    Posté par  . Évalué à 1.

                    Je n'ai rien contre Java en général, je constate juste que TOUS les sites en jsp ou autre rament avec un modem 56k ( je teste toujours les applis web avec un 56k ). Alors que TOUT ce que j'ai vu réalisé en Zope est fluide et rapide. Pour le développement, Java est sûrement plus agréable, mais pour la performance il n'y a vraiment pas photo. La différence est suffisemment éloquente pour que je prie tous les soirs que la version 3 de Zope soit moins "uzine à gaz" que les précédentes...

                    • [^] # Re: Interprété ou compilé ?

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

                      et beh, ca, c du test... ton test ne prend même pas en compte le nombre d'utilisateurs du site, l'infrastructure réseau (débit) et la (les) machines qui hébergent l'application...

                      Je trouve que des sites comme l'ANPE ou http://java.sun.com/ qui tournent sur une platefome Java tournent hyper bien.

                      http://about.me/straumat

                      • [^] # Re: Interprété ou compilé ?

                        Posté par  . Évalué à 0.

                        Mea culpa, je me suis lancé dans un troll sans rappel. J'ai fait mes tests sur la même machine. Il s'agissait d'un test basique : requête SQL et LDAP et affichage des résultats dans une page à l'intérieur d'une balise div CSS1. C'est vrai que je n'ai testé ni le nombre d'utilisateurs ni la stabilité, ni la montée en charge. Reste qu'au niveau perf... il n'y avait pas photo... Et vraiment j'essaie d'être objectif parce que je trouve que Zope est quand même une sacrée uzine à gaz. Je tue le troll Zope/J2EE que j'ai invoqué...

                      • [^] # Re: Interprété ou compilé ?

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

                        >Je trouve que des sites comme l'ANPE ou http://java.sun.com/ qui tournent sur une platefome Java tournent hyper bien.

                        En même temps vu que le site de l'ANPE est fait en partie avec PHP c'est normal que ca tourne bien ;)

                        http://solutions.journaldunet.com/0504/050422_anpe_spip_agor(...)

                      • [^] # Re: Interprété ou compilé ?

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

                        Pour une fois qu'il y a quelque chose qui marche à l'ANPE (je parle en connaissance de cause)...

                        ok, je --->[]

                        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                    • [^] # Re: Interprété ou compilé ?

                      Posté par  . Évalué à 4.

                      Euh ...
                      56k ou pas 56k, ça change quoi au temps de génération de la page ?
                      Rien

                      • [^] # Re: Interprété ou compilé ?

                        Posté par  . Évalué à 3.

                        Ça ne change en effet rien au niveau de l'exécution du script côté serveur, mais ça permet de se mettre à la place du client et de se poser la bonne question : la vitesse est-elle supportable ou pas ? C'est peut-être subjectif, mais un client se moque éperdument de savoir qu'il y a 100000 requêtes simultanées sur le serveur. ou qu'une base contient 2 millions d'enregistrements. Il veut SA réponse, et tout de suite, sachant qu'au bout de 20s en moyenne, il clique sur reload et maudit son service informatique...

                        • [^] # Re: Interprété ou compilé ?

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

                          Qu'un utilisateur fasse ce genre d'erreur de raisonnement, c'est compréhensible. Mais qu'un développeur choisisse et se fasse une opinon sur une technologie en se basant sur la vitesse de téléchargement d'un site qu'il a pas fait avec un modem 56K.. c'est un pru ridicule.

                          http://about.me/straumat

                          • [^] # Re: Interprété ou compilé ?

                            Posté par  . Évalué à 1.

                            Seigneur c'est ma faute, ma très grande faute... J'avais fait ce test il y a deux ou trois ans. A l'époque le ministère de l'intérieur annonçait publiquement son choix de Zope ( peu connu ) alors que le monde entier avait les yeux rivés sur Tomcat, Jboss, Jonas... Je m'étais alors interressé à Zope (v. 2.7) et j'avais réalisé un test somaire, à partir d'une bdd SQL de 60000 enregistrements et d'un annuaire LDAP de 700 noms. J'avais écrit et testé 2-3 requêtes basiques. C'était brut, rapide. Rien n'était optlmisé. N'empêche, depuis je crois très fort en Zope et j'affronterai mon Troll les yeux dans les yeux :-).

            • [^] # Re: Interprété ou compilé ?

              Posté par  . Évalué à 2.

              "Il suffit de quelques minutes d'utilisation pour constater qu'une application sous Zope va vite, vraiment vite..."

              Tu rigoles la j'espère ... ?

  • # Ptite correction orthographique

    Posté par  . Évalué à 5.

    Désolé avec ça, mais ça m'agace :

    les nouveautés du moteur Zend2 devraient permettre d'obtenir d'encore de meilleures performances grâce entre autres à une gestion plus fine de la mémoire.
    (...)

    PHP est un langage interprété créé en 1994 par Rasmus Lerdorf. (...) le moteur fut réécrit et publié en 1997 sous le nom PHP3 signifiant PHP Hypertext Preprocessor. PHP4 est sorti en 2000 (...) un grand nombre de nouveautés telles qu'une nouvelle orientation résolument objet ou le support simplifié et amélioré des technologies XML. (...)

    • [^] # Pendant qu'on y est

      Posté par  . Évalué à 10.

      Corrigeons la correction :

      les nouveautés du moteur Zend2 devraient permettre d'obtenir d'encore de meilleures performances

      ou

      des performances encore meilleures, ça sonne même mieux.

  • # PHP6

    Posté par  . Évalué à 2.


    "PHP6 est déjà sur les rails avec de nombreuses nouveautés"


    En particulier le tant attendu support unicode natif (autrement urgent que le support des objets, mais c'est un avis perso).

    Et ça, c'est vraiment une bonne nouvelle qu'on attendait depuis longtemps :-D

    Non pas que le support unicode natif, ce soit un truc qui se fait tout seul (et je parle pas des problèmes de perfs qu'ils auront à résoudre).

  • # Date, je casse tout #2

    Posté par  . Évalué à 8.

    Il faudrait peut-etre attendre, Derick Rethans nous l'a refait, il a active du code qui n'aurait jamais du l'etre avant la RC6 (avant derniere version de test). Du coup, on se trouve avec une nouvelle classe interne Date... et vide.

    Cela risque de poser problemes a beacoup de monde, une 5.1.1 est envisigee, dans les 2-3 jours.

    • [^] # Re: Date, je casse tout #2

      Posté par  . Évalué à 3.

      Confirme, 5.1.1 va etre disponible d'ici demain.

      La nouvelle "classe" Date a ete supprimee et quelques bugs importants.

      Voir le fichier NEWS pour les impatients:
      http://cvs.php.net/co.php/php-src/NEWS?r=1.2027.2.234

    • [^] # Re: Date, je casse tout #2

      Posté par  . Évalué à 1.

      Heu si je ne m'abuse en RC on ne s'amuse plus à ajouter / enlever du code hors correction de bug non ?

      • [^] # Re: Date, je casse tout #2

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

        toi tu n'as jamais vu comment se passe les décisions dans le projet PHP.

        Grosso modo on parle bien d'un nouveau code, non fini, qui est contesté publiquement par certains (principalement par paj qui poste plus haut), dont n avait dit qu'il ne serait pas intégré, et qui a été ajouté sans annonce publique dans la dernière RC (rc6) qui a précédé d'une petite semaine la release publique.
        Pour l'anecdote le release master a même donné sa conclusion en sous entendant fortement que les problèmes survenus suite à cet ajout ont pour cause un manque de test de la rc6 de la part des détracteurs (et pas de l'ajout de dernière minute)

        Malheureusement ce n'est pas chose si rare. Des trucs énormes comme ça on en a vu plein dans PHP. Grosso modo tant que ça plait à la dizaine de personnes qui chapottent PHP, ça passe. Que ce soit testé, complet, intelligent, réfléchi, contesté ou pas n'influe que très peu.

  • # Et Oracle ??

    Posté par  . Évalué à 2.

    Je désespère de faire fonctionner correctement l'API OCI8 dans PHP 4.3.10 de Debian et l'instant client livré par Oracle... l'ensemble crashant en beauté avec corruption de pile dans l'interpréteur PHP.

    Alors quand je vois que même PHP 5.1 fournit une API qui ignore Oracle (pas dans la liste présentée en tout cas), je me dis que je ne suis pas au boût de mes peines.

    Bien sûr si quelqu'un a réussi à compiler PHP 4.3.10-15 Debian Sarge 3.1 avec le support OCI8 (classique ou instant client), je suis preneur de la solution. Merci d'avance.

    • [^] # Re: Et Oracle ??

      Posté par  . Évalué à 2.

      pdo_oci est peut-etre ce que tu as manque.

      Il y a eut bcp de travail fait pour le support Oracle,
      http://pecl.php.net/package/PDO_OCI
      et
      http://pecl.php.net/package/oci8

      Par contre tu peux commencer a oublier php4...

      • [^] # Re: Et Oracle ??

        Posté par  . Évalué à 5.

        Petite erreur, le package oci8 fonctionne avec php4, donc bonne nouvelle.

        Si tu as des problemes ou des requetes, je te suggere de poster sur la liste pecl-dev de php, les auteurs Antony et Wez sont tres reactifs.

  • # "PHP6 est déjà sur les rails"

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

    Ah non je proteste, c'est Ruby qui est sur les rails :-)

  • # upload progress monitor

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

    Toujours aucune possibilité de fabriquer une barre de progression d'upload sans bidouiller ? (càd sans patcher php, ni ajouter du perl)
    C'est dommage de ne toujours pas intégrer un truc comme http://pdoru.from.ro . Surtout pour beaucoup de projets qui permettent d'uploader des fichiers, mais pas de savoir le temps que ça prend ni l'avancement.

    • [^] # Re: upload progress monitor

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

      Question bête, ce ne serait pas au navigateur de le faire ?
      Car lui, il sait tout du fichier envoyé ... non ?

    • [^] # Re: upload progress monitor

      Posté par  . Évalué à 2.

      Ce n'est pas un manque de PHP mais du fait que le protocole HTTP est synchrone et que PHP est executé côté serveur.

      Donc même si un jour PHP proposait une solution, ce serait forcément un détournement du fonctionnement du protocole.
      La solution dont tu parles n'est d'ailleurs rien d'autre qu'une bidouille. Je ne suis pas partisan de l'intégration de ce type de bidouille au sein de PHP ni même d'un autre langage.

      Rien ne t'empêche d'utiliser Ajax pour trouver une solution.

      Si vous n'aimez pas ce commentaire c'est qu'il est ironique.

Suivre le flux des commentaires

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