Sortie de PHP 5.0.0

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
14
juil.
2004
PHP
La version 5.0 de PHP est disponible. Le ChangeLog indique la correction d'une vingtaine de bugs et une modification mineure du module PCRE par rapport à la RC3.

Pour rappel, cette nouvelle version intègre le nouveau moteur Zend Engine 2 qui apporte trois grandes nouveautés :
- Simplification de l'utilisation d'XML grâce entre autres à l'API SimpleXML;
- Un modèle objet enfin digne de ce nom;
- L'intégration d'une (mini) base de données embarquée : SQLite.

A cela, on peut également ajouter divers changements comme des améliorations au niveau de GD (la bibliothèque de gestion d'images) ou l'apparition de nombreuses nouvelles fonctions.

Cette nouvelle version comble une bonne partie des manques des précédentes versions et évolue pour sortir PHP de son image de "langage pour page perso" tout en restant accessible.

NdM : merci également à Scullder et tous les contributeurs.
mise à jour : PHP 4.3.8 est aussi sorti corrigeant des failles de sécurité. Rappelons que PHP est un langage interprêté, créé en 1995, ayant connu une forte croissance de sa communauté dès 1998, lorsque PHP 3 est sorti, apportant un moteur de script mature et prêt à gérer des sites dynamiques de grande envergure. PHP 4 est sorti en 2000 pour arriver aujourd'hui à la version 4.3.8 avec ses corrections de bug. Dans un registre plus important, PHP5 prend le relai dont voici une liste non exhaustive de ses améliorations :

Au niveau objet :
- quelques contrôles de programmation (déclaration des méthodes statiques, méthodes et attributs privés/protégés/publics, interfaces, classes/méthodes abstraites et finales)
- quelques fonctionnalités supplémentaires (interceptions des lectures/écritures d'attributs inexistants ou des appels aux fonctions inexistantes)
- le passage par référence de tous les objets (en PHP4 les objets sont passés par valeur, comme toutes les variables, donc par défaut clonés à chaque affectation ou passage en paramètre de fonction)
- le déréférencement des méthodes (possibilité de faire $a->b()->c)

Manipulation des fichiers et des structures XML :
- une interface "simple" pour lire du XML, nommée SimpleXML
- une nouvelle interface DOM standard relativement complète (basée sur la libxml)
- une interface Xpath utilisant les objets DOM et SimpleXML
- l'intégration de la libxslt pour les traitements XSLT

Pour les SGBD :
- la bibliothèque cliente de MySQL n'est plus fournie avec PHP, il vous faudra la demander explicitement lors de la compilation
- en échange la bibliothèque sqlite (base de données embarquée, http://www.sqlite.org(...)) est fournie et intégrée par défaut dans sa version 2.8 (pas de version 3.0 pour l'instant)

Aller plus loin

  • # SQLite

    Posté par  . Évalué à 6.

    Je m'en vais de se pas voir les nouveautées de PHP5 ! :)

    Mais avant je me pose une petite question sur l'ajout de cette extension SQLite, ca va jusqu'ou ?
    Je peux faire mon petit script de news avec ou c'est vraiment trop limité ?
    Je pourrais faire tout un forum avec et en fait c'est vraiment trop balèse ?
    Niveau performances aussi toussa :)

    • [^] # Re: SQLite

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

      Je te propose de regarder http://linuxfr.org/2004/06/19/16605.html(...)
      Pour des applications à faible concurence en écriture c'est largement du niveau d'un MySQL au niveau perf. Souvent meilleur pour des petits trucs vu qu'on saute les phases de connexion/authentification.
      Coté fonctionnalités on est grosso modo au niveau d'un MySQL 3.23 avec en plus la possibilité d'utiliser ses propres fonctions utilisateur dans les requêtes SQL.

      Aucun problème à mon avis pour un petit script de news ou un forum avec un traffic faible/moyen (type pour une assoc). Même chose si tu as un bon système de cache qui limite largement les accès aux données (type ce que fait linuxfr).
      Maintenant je crois que tout le monde sera d'accord pour dire que le but et les applications de Sqlite ne sont pas les mêmes que PostgreSQL ou Oracle. La question est de savoir si pour une énorme proportion de scripts PHP on a effectivement besoin d'un gros poids lourd en SGBD (l'utilisation massive de Mysql 3.23 m'incite à dire que non) et qu'un truc léger et simpliste ne serait pas aussi adapté, voire plus efficace.

      Un des avantages de sqlite c'est que tu peux diffuser une appli qui utilise une DB sans avoir de pré-requis coté présence d'un SGBD, sans étape de configuration/installation pour faire les tables/bases/droits dans ton SGBD, sans besoin de manip spéciales pour les sauvegardes.
      Maintenant je crois

      • [^] # Re: SQLite

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

        Si les applis comme dotclear, phphorum, spip et autres sont ré-écrites, cela va incroyablement facilité leur déploiement. C'est un plus indéniable pour les néophytes qui récupèrent des solutions de publications mais qui galèrent pour le mettre en place chez leur FAI.

        Par contre, cela doit être galère pour faire migrer un site php5 de sqllite vers un truc plus puissant....

        • [^] # Re: SQLite

          Posté par  . Évalué à 4.

          Si les applis comme dotclear, phphorum, spip et autres sont ré-écrites, cela va incroyablement facilité leur déploiement.

          Oui, c'est juste qu'il va falloir les réécrire ;)
          (envoyez-moi des sioux)

          En plus, SQLite est vraiment minimaliste au niveau des fonctions par défaut, et il ne supporte pas les ALTER TABLE. Va falloir se retrousser les manches...

          • [^] # Re: SQLite

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

            En plus, SQLite est vraiment minimaliste au niveau des fonctions par défaut, et il ne supporte pas les ALTER TABLE. Va falloir se retrousser les manches...

            Ca va être du vite réglé alors... Phpmyadmin et mysql !

          • [^] # Re: SQLite

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

            Les fonctions sont quasi inexistantes mais la capacité d'exporter des fonctions PHP pour s'en servir dans les requêtes SQL comble quasi complètement ce manque.
            Pour les ALTER c'est vrai, et le paliatif (faire une table à coté et copier les données) n'est pas top. Ceci dit pour les types d'appli visées par sqlite, les alter n'arrivent pas tous les jours. Si c'est juste pour les étapes de migration, le paliatif est suffisant. C'est juste agacant lors des développements en fait.

            • [^] # Re: SQLite

              Posté par  . Évalué à 4.

              Pour les ALTER c'est vrai, et le paliatif (faire une table à coté et copier les données) n'est pas top. Ceci dit pour les types d'appli visées par sqlite, les alter n'arrivent pas tous les jours. Si c'est juste pour les étapes de migration, le paliatif est suffisant.

              En fait ça peut être chiant si tu développes un logiciel déployable chez un hébergeur mutualisé, notamment avec un quota disque limité. Si une table importante de ta base de données double de taille lors de la migration et que ça fait exploser le quota, tu peux avoir des problèmes.

        • [^] # Re: SQLite

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

          Pour DotClear, il y a un patch SQLite et je compte bosser sur le sujet de façon plus complète. Il n'y a rien de compliqué et pas besoin de tout réécrire. Certaines requêtes on besoin d'être un peu changées, quelques problème de formatage de date, rien de bien méchant donc. Ça viendra avec le support PostgreSQL.

    • [^] # Re: SQLite

      Posté par  . Évalué à 8.

      Si on regarde sur sqlite.org, on peut voir ceci : "Implements most of SQL92."
      donc je pense que ce n'est pas limité au niveau des fonctionnalités.
      En ce qui concerne l'utilisation, j'ai regardé un peu là : http://www.php.net/manual/fr/ref.sqlite.php(...)
      ça ne me semble pas plus dur et peut s'avérer pratique dans certain cas où on ne dispose pas de bdd sur un serveur mysql ou autre (quand certains hébergeurs les font payer en supplément), ou encore pour faire une application cliente en php (de l'amusement avec la prochaine version de php gtk en prévision ^^, qui doit arriver avec php 5 si ça n'a pas changé), ou dans bien d'autres cas (sauf nombreux accès concurrentiels à la bdd).

    • [^] # Re: SQLite

      Posté par  . Évalué à 1.

      Merci aux gens du dessus, ca va être une petite révolution ce sqlite :D

    • [^] # Re: SQLite

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

      Le principal pbm de SQLite c'est que ca gère tres mal les accès concurents.
      Quand tu ecrit ca fait un lock et du coup tes requetes en lectures sont mises en attente.
      En gros c'est surtout interessant quand tu as surtout besoin de faire de la consultation.

      De mon coté je vois sqlite comme un tremplin pour le couple PHP/GTK. Il est maintenant possible de faire des applications type client riche avec une base de données intégrées.
      Par exemple jke peux facilement migrer l'annuaire que j'ai développé pour l'intranet vers une solution PHP/GTK disponible sur cdrom.

      ++

      cyril

      • [^] # Re: SQLite

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

        > Par exemple jke peux facilement migrer l'annuaire que j'ai
        > développé pour l'intranet vers une solution PHP/GTK disponible sur cdrom.

        Intéressant, effectivement. Tu parles ainsi d'utiliser PHP en dehors d'apache mais avec un environnement GTK ? J'ai justement un problème de base de données que je souhaite consulter sans devoir trimbaler un serveur web sur cdrom...

        As-tu des pistes (ou un livre :-o) pour pouvoir faire une consultation d'une base de données avec PhP/MysqlL/GTK. L'idéal étant de faire un support multi-plateforme.

        Ô grand merci d'avance.

  • # Evolution ?!?

    Posté par  . Évalué à 2.

    J'utilise dans le cadre dans le cadre mon stage la RC3 de php5, et il m'est apparu en devellopant avec cette nouvelle mouture que le php acquiert de plus en plus de similarites avec le perl. Je trouve que le php part un peu trop dans toutes les directions et bien qu'il des qualites claire, il n'en reste pas moins un langage de script fait a la base pour le web et qui n'apporte en dehors de cela rien de plus (faire une chose bien est mieux que de faire plein de choses moins bien ... )

    • [^] # Re: Evolution ?!?

      Posté par  . Évalué à 6.

      J'utilise dans le cadre dans le cadre mon stage la RC3 de php5, et il m'est apparu en devellopant avec cette nouvelle mouture que le php acquiert de plus en plus de similarites avec le perl.

      PHP est une émanation de perl, à la base... jusqu'à la version 2, PHP (alors appelé php/fi si je ne m'abuse) était une bibliothèque pour perl. Ces deux langages ont le meme point fort : la manipulation de chaines de caractères... C'est bien normal que les langages et les fonctionnalités se rejoignent, au moins partiellement.

      Il n'en reste pas moins un langage de script fait a la base pour le web et qui n'apporte en dehors de cela rien de plus

      Pas d'accord : à part quelques projets clairement "pour le fun", php démontre des capacités dans d'autres domaines et c'est tant mieux : cela permet de réutiliser les compétences et les scripts déjà développés dans d'autres contextes que celui, initial, des pages web dynamiques (quelques exemples : les moulinettes de maintenance (merci le shell), les interfaces d'administration en GTK et bientot en GTK2...).

      • [^] # Re: Evolution ?!?

        Posté par  . Évalué à 1.

        Ouais, sauf que pour ces applications, il y a des langages bien plus adaptés, par exemple PHP est bien moins adapté à l'administration système que Perl justement... Donc réutilisation des compétences, d'accord, mais utiliser un langage pour une tâche pour laquelle il n'est pas le plus adapté n'est pas toujours une bonne politique. :-(

        --
        Jedaï

    • [^] # Re: Evolution ?!?

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

      il n'en reste pas moins un langage de script

      Et le fait de pouvoir développer en objet ? On dit pas que c'est un langage objet ?


      qui n'apporte en dehors de cela rien de plus (faire une chose bien est mieux que de faire plein de choses moins bien ... )

      Quand tu parles de Web c'est reducteur. Avec PHP tu peux gérer la majorité des applications type client serveur. Autant dire énormément de choses...

      Je t'invite à consulter le livre blance de l'AFUP (www.afup.org) pour en savoir plus ...

  • # clonés

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

    - le passage par référence de tous les objets (en PHP4 les objets sont passés par valeur, comme toutes les variables, donc par défaut clonés à chaque affectation ou passage en paramètre de fonction)

    Quelle curieuse décision (pour PHP4). Quelqu'un en connaît la raison ?

    • [^] # Re: clonés

      Posté par  . Évalué à 1.

      Ben il me semble que c'est un classique de beaucoup de langage (si mes souvenirs de C++ sont bons, pour passer un paramètre en référence, il faut l'indiquer dans le prototype de la fonction, par un & devant ledit paramètre, sinon celui-ci est cloné).

      • [^] # Re: clonés

        Posté par  . Évalué à 5.

        Dans le cas de C++ c'était une compatibilité avec la sémantique du C, et le caractère explicite des mode de passage de paramètre dans ce langage. Il aurait été curieux que les "struct" aient été passées par valeur par défaut, mais les "class" par référence.

        PHP n'avait pas cette contrainte et il aurait pu faire un choix intelligent dès le début ;))

        • [^] # Re: clonés

          Posté par  . Évalué à 0.

          Il aurait été curieux que les "struct" aient été passées par valeur par défaut, mais les "class" par référence.

          D'autant que, comme dans la plupart des programmes on indique explicitement les public/private, les deux sont en interchangeables dans la pratique.

          PHP n'avait pas cette contrainte et il aurait pu faire un choix intelligent dès le début ;))

          En C++ il y a certes la compatibilité C, mais on manipule aussi explicitement les références et les pointeurs. Dans ce cadre là, ça me paraît plus logique de tout passer par valeur. Je ne connais pas le PHP, vos remarques viennent du fait que les objets y sont traités indirectement comme en Java ?

    • [^] # Re: clonés

      Posté par  . Évalué à 1.

      Pourquoi curieux? (c'est une question pas un appel à la vendetta des trolls)
      Certes cela oblige certainement à revoir le code de quasimanent toutes les applis.
      Mais d'un autre côté cela me paraît plus logique de travailler une instance d'objet et pas sa copie. De plus niveau perf, est-ce que cela ne sera pas plus rapide?

      • [^] # Re: clonés

        Posté par  . Évalué à 3.

        Je crois que sa remarque était plutôt que c'est curieux que PHP4 soit fait ainsi.

    • [^] # Re: clonés

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

      Si je ne me trompe pas Sun et Zend ont travaillé ensemble pour améliorer l'intégration de PHP et Java.
      Sun veut faire de PHP le VisualBasic des plateformes Java. C'est pour celà que PHP5 a des nombreuses similitudes avec Java.

      http://www.zend.com/news/zendpr.php?id=63(...)

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: clonés

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

        Sun veut faire de PHP le VisualBasic des plateformes Java. C'est pour celà que PHP5 a des nombreuses similitudes avec Java.

        ?
        Rien à voir.
        Zend et Sun se sont rapproché pour faire une extension permettant de faire appel à des objets Java. Ca implique que dans le cas ou tu développe une application en PHP dans un environement Java existant ce ne sera pas la peine de tout redevelopper. On apelle ca de l'interopérabilité.
        Et Java n'est pas, et de loin, la seule technologie avec laquelle PHP soit interopérable.

        • [^] # Re: clonés

          Posté par  . Évalué à 2.

          Sufit de voir les fonctions d'interop avec .Net :D

    • [^] # Re: clonés

      Posté par  . Évalué à 0.

      ce n'est pas "curieux" (c'est un jugement subjectif)

      la motivation c'est que si les objets sont passés en reference une fonction peut manipuler les valeurs de l'objet via ses méthodes, à la sortie de la fonction, l'objet "conserve" les modifications.
      Pour limiter la source de nombreux bugs difficile à trouver que selon les auteurs de php , les développeurs php ont souvent, ils ont décidé que le passage d'objet se fait automatiquement par référence.

      Cela change aussi beaucoup pour ce qui se passe quand on fait un "constructeur" statique qui renvoie des instances de classes (un $myMotor = Motor::newMotorFactory("ford"); par exemple)

      plusieurs langages dit objets procèdent ainsi.

      • [^] # Re: clonés

        Posté par  . Évalué à 2.

        Lis le post au quel tu réponds : (pour PHP4). !!!

        • [^] # Re: clonés

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

          par contre, au milieu de son explication assez bizarre (il défend le contraire de ce qui a été fait, si je comprends bien.. mais je suis pas sûr de bien comprendre ;p) on peut peut-être supposer que c'était la raison de la décision jusqu'à PHP4 : pour éviter aux neuneus, enfin, programmeurs php, de niquer leurs "vrais" objets on ne donnait que des copies aux fonctions comme ça elles pouvaient les exploser si ça leur chantait.

          cependant, un tel changement implique quand même beaucoup de choses pour les programmes et ça risque de surtout être un cauchemard pour débugger les applications PHP existantes qui ont des fonctions qui modifient les objets passés en paramètre (à moins qu'une syntaxe existe pour les passer sélectivement par valeur si nécessaire).

          c'est pas dacode qui est en php :) ?

          • [^] # Re: clonés

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

            hum je ne sais plus quoi penser en fait.

            si on obtient une copie par valeur d'un objet dans une fonction, ou une méthode d'une autre classe, effectivement ça devient difficile de changer l'objet, mais c'est quand même ce qu'on veut faire très souvent dans un programme objet.. je ne vois pas trop comment on peut ensuite s'en tirer pour faire un programme qui puisse faire quelque chose d'intéressant :)

          • [^] # Re: clonés

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

            > ça risque de surtout être un cauchemard pour débugger les
            > applications PHP existantes qui ont des fonctions qui modifient les
            > objets passés en paramètre (à moins qu'une syntaxe existe pour les
            > passer sélectivement par valeur si nécessaire).

            Le déboggage va être très long pour les applis non documentées. Se rendre compte si on utilise ou pas le passage par copie n'est pas simple.
            Maintenant en pratique il est très rare qu'on *veuille* un passage par copie lors des appels. La plupart des applis objet PHP4 soit n'utilisent les objets que basiquement (en lecture, peu de passages en paramètres, pas d'affectation ...) soit utilisent des & à profusion pour forcer le passage par référence.
            Dans l'ensemble je pense que pour la plupart des codes la transition se fera sans modification. Le problème va juste être de pouvoir garantir qu'il n'y a pas besoin de modif (vu que traquer les passages par copie pour voir s'ils sont utilisés ou si une référence peut aller .. c'est très long et sujet à erreurs)

          • [^] # Re: clonés

            Posté par  . Évalué à 1.

            Bah dans le php.ini au je crois que l'on peut forcer l'ancien comportement...

  • # SimpleXM

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

    SimpleXML : l'interface "simple" pour lire du XML à l'air de tuer, en particulier pour faire du developpement rapide =)

    Un appel de fonction et hop, on a un tableau remplit !

  • # PHP 4.3.8

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

    Ca aurait été pas mal de dire que PHP 4.3.8 est sorti et qu'il est vivement recommandé de mettre à jour pour des questions de sécurité.
    (Vous me direz, peut être qu'une autre news est prévue)

    • [^] # Re: PHP 4.3.8

      Posté par  . Évalué à 1.

      En fait, c'est marqué :) dans le début de la seconde partie mais ce n'était pas le sujet principal.
      Et il n'y a pas d'autres news en attente sur le sujet. D'ailleurs, y a plus rien en attente.

      • [^] # Re: PHP 4.3.8

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

        il n'est pas marqué qu'il y a des problèmes de sécurité et c'est vraiment dommage parce que c'est à peu près la seule chose à ne pas louper sur cette version.
        d'ailleurs en lisant cette news, on n'a pas l'impression que cela vient de sortir mais que ca fait juste partie de l'historique.

        • [^] # Re: PHP 4.3.8

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

          J'aurais bien ajouté une Note des Relecteurs mais quand une news a été publiée on ne peut plus la modifiée :(

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Re: PHP 4.3.8

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

            s/modifiée/modifier/
            domi< grillai !

            L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Dispo pour debian "woody"

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

    Pour ceux que ca intéresse, j'ai mis des paquets debian non officiels (concoctés dans le cadre de mon job chez Nexen) disponibles sur http://www.dotdeb.org/(...)

    Et PHP 4.3.8 est en ce moment même dans la deb-moulinette :)

    Ceux-ci sont pour Woody, mais devraient fonctionner sans souci sur une sarge/sid.

    • [^] # Re: Dispo pour debian "woody"

      Posté par  . Évalué à 1.

      Je confirme, sous SID, aucun souci ;)

    • [^] # Re: Dispo pour debian "woody"

      Posté par  . Évalué à 1.

      pour instable j'ai du récupéré libmm11 de stable (ou testing je ne sais plus) car le paquet dans instable est libmm13

      merci bien pour ces paquets, la migration php4 php5 a été transparente pour mon site et tout fonctionne comme il faut.

      Juste une question, a quand l'intégration des paquets dans l'arbre officiel de debian ?

      • [^] # Re: Dispo pour debian "woody"

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

        mes paquets ne seront ps inclus dans la distrib officielle, vu que je ne suis pas developpeurs officiels Debian (meme si ca serait le top de le devenir. Si qqn de competent lit ces lignes...).

        php 4.3.8 vient de rentrer dans debian unstable. php5 est prevu d ici qq temps, ca sera les memes mainteneurs que les paquets php4 actuels a priori.

        Voila!

  • # PHP, un language interprété??!

    Posté par  . Évalué à 4.

    Attention, cette avis vient du tréfond de ma mémoire donc peut être faux donc vous savez à quoi vous en tenir....

    Je crois avoir lu que pour des problèmes de performence lors de la consultation d'une page, le Zend Engine compile en fait les pages lors de la première consultation de la page et que part la suite la page est déjà compilée. Il était dit que cette tendance (qui rejoint d'une certaine façon la compilation necessaire des jsp) s'etendait à tous les language web interprétés.

    Ma question est donc la suivante : Peut-on encore dire que le php est un langage interprété? La différence est elle seulement que la compilation est automatique et non faite à la main, et est transparante à l'utilisateur?

    Je remercie d'avance toute personne qui se penchera sur ma question ;)

    • [^] # Re: PHP, un language interprété??!

      Posté par  . Évalué à 4.

      PHP à la base est un language interprété;
      Après tu peux passer en bytecode avec le moteur Zend pour optimiser les temps de réponses.

    • [^] # Re: PHP, un language interprété??!

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

      Le PhP est interprété au sens où l'exécution ne nécessite pas les phases de compilation, édition de lien puis exécution. Il suffit d'avoir l'interpréteur et ça marche. Le programme est indépendant du système, sauf évidemment pour des cas d'accès aux fichiers, par exemple.

    • [^] # Re: PHP, un language interprété??!

      Posté par  . Évalué à 3.

      PHP est comme beaucoup de langages de scripts modernes : il compile dans un code intermédiaire puis exécute ce code intermédiaire.

      Certains outils permettent de sauvegarder ce code intermédiaire et de contourner l'étape compilation pour aller directement à l'exécution.

      APC ( http://apc.communityconnect.com/(...) ) le fait par exemple.

      Donc, PHP est vu comme un langage interprété (comme un script shell) mais ne se comporte pas exactement comme tel à l'intérieur.

    • [^] # Re: PHP, un language interprété??!

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

      hum.. soit il compile en limitant le langage, soit il ne peut pas tout compiler, par exemple un appel à eval avec argument dynamique, ou alors il doit mettre tout php dans le binaire final (ou alors c'est du bytecode executable par une machine virtuelle qui contient aussi tout php).

  • # Packages Mandrake

    Posté par  . Évalué à 1.

    Est ce que vous savez où trouver des packages rpm pour Mandrake 10 (avec tous les modules quivontbien) ?

    Je ne connais pas encore de backport de ce type de logiciels, assez différents de ceux habituels de plf ;)

    Merci d'avance,

  • # SOAP extension

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

    A brand new built-in SOAP extension for interoperability with Web Services.

    Quelqu'un a essayé cette nouvelle extension SOAP ? Le support du SOAP en php 4.x c'était limite de l'arrachage de cheveux, mais au final ca marchait pas mal (mais très lourd à maintenir...).
    Qu'est ce qu'apporte cette nouvelle extension ?

    • [^] # Re: SOAP extension

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

      Toutes les infos sont là : http://fr.php.net/SOAP(...)

      Attention toutefois. On en parle mais cette extension n'est pas finalisée ni considérée comme stable. Elle a été intégrée avec PHP5 car on la considère comme importante et devant être finalisée au plus vite (donc testée/utilisée), mais c'est tout.

  • # PHP5 sans MYSQL sous Windows

    Posté par  . Évalué à 1.

    La dll fournie avec php5 pour l'utilisation de MySQL est buggée de sorte qu'on se retrouve devant une page disant que php ne comprend pas les fonctions mysql.
    Pour rectifier le tir ; il faut telecharger une version nightly build....

Suivre le flux des commentaires

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