PHP 5.1 est sorti, SAUF QUE...
PHP 5.1 est sorti hier avec pas mal de gros changements :
- Une ré-écriture complète de la gestion des dates ;
- Des performances améliorées par rapport aux versions 5.0.x ;
- Pas moins de 30 nouvelles fonctions ;
- Plus de 400 bugs corrigés ;
- Mises à jour des versions de PCRE, SQLite, PEAR, etc.
Tout cela est bel et bien beau SAUF QUE, pour ma part, plusieurs choses me chiffonnent.
La guerre des langages de programmation
Après la guerre des systèmes d'exploitation (tout le monde se prépare à contrer la sortie de Windows Vista), après la guerre des navigateurs (lire à ce propos le billet de Tristan Nitot intitulé Un allié de poids pour Firefox), nous voici à l'ère de la guerre des langages de programmation : il faut encore et toujours être meilleur, plus rapide et plus performant que les autres et les versions se succèdent à un rythme fou. Le but avoué de PHP 5 (et du futur PHP 6) est bien de pouvoir atteindre, voire dépasser les concurrents comme .NET ou Java afin de pouvoir aussi jouer dans la cour des grands et s'imposer en entreprise...
Mais que faire d'une version PHP 5.1 alors que PHP 4 est encore présent à plus de 94% sur les serveurs (source Nexen.net, pour le mois d'octobre 2005) ? Ce qui me fait peur, c'est que PHP 6 est déjà en chantier (lire par exemple Sitepoint : PHP6 Planning ou Minutes PHP Developers Meeting)...
PHP s'alourdit
Dans son annonce de sortie de PHP 5.1, Armel Fauveau de PHPIndex souligne :
A propos des fonctions faisant une première apparition avec cette nouvelle version de PHP, certaines semblent totalement inutiles. Citons le cas de array_product(). On ne peut que déplorer la surcharge permanente de PHP, au fil des versions, par des fonctions built-in d’un intérêt plus que douteux.
En effet, j'ai remarqué que sous Windows, le fichier php5ts.dll qui contient l'ensemble des fonctionnalités de PHP est passé de 3 557 Ko à 4 173 Ko, soit une augmentation d'environ 500 Ko ! J'espère que ça n'est pas au détriment des performances...
Et la compatiblité dans tout ça ?
Un des problèmes classiques dans un changement majeur de version, c'est la compatibilité avec les versions précédentes... J'ai eu la joie d'avoir quelques problèmes lors de tests avec cette version 5.1.
J'ai développé un script en ligne de commande qui fonctionne très bien en PHP 5.0.5 et qui "plante" lamentablement avec la version 5.1, voici la fonction incriminée :
<?php
function wscriptRun( $strCommand, $bWaitOnReturn = FALSE ) {
$cmdline = "cmd /C $strCommand";
$WshShell = new COM("WScript.Shell");
$oExec = $WshShell->Run($cmdline, 0, $bWaitOnReturn);
return $oExec;
} // end of 'wscriptRun()'
?>
Cette fonction permet de lancer un programme externe via le Windows Script Host présent sur Windows en passant par les fonctions COM. Le fait de passer par cette fonction me permet de lancer des applications comme Apache ou MySQL de manière totalement parallèle et de continuer mon script PHP courant. Le fait est qu'en PHP 5.1, le script se termine brutalement, sans autre forme de procès...
Autre exemple, j'ai découvert récemment l'extension WinBinder permettant de créer des applications Windows en PHP et là encore, plantage avec PHP 5.1 ! Il s'agit cette fois d'une erreur au chargement de l'extension indiquant que la fonction _zval_copy_ctor ne peut pas être localisée dans la librarie php5ts.dll alors qu'il n'y avait aucun soucis de ce genre avec les versions précédentes de PHP ; j'ai fait une erreur quelque part ?
Toujours concernant la compatibilité, il faut encore noter - entre autres - un problème avec les sessions ; mais fort heureusement le PHP Group a créé une procédure de mise à jour permettant de voir ce qui fonctionnera ou ne fonctionnera plus lors du passage vers la version 5.1 ; ouf, nous voilà sauvés !
Mise à jour du 29 nov. : la version 5.1.1 est annoncée ! Déjà des corrections de bugs dont la suppression d'une erreur fatale quand un fichier se termine par un commentaire (si, si, tu parles d'une avancée !) et surtout la suppression de la classe Date afin d'éviter un conflit avec la classe PEAR::Date. Mais si on en croit ce commentaire sur Linuxfr.org, il s'agit surtout de retirer une classe Date vide qui a été introduite dans la dernière version RC de PHP 5.1...
Commentaires
-
Oliv' a écrit le 26/11/2005 :
J'ajouterai à ce post d'aller lire cet article sur php 6 :
www.corephp.co.uk/[...]/19-Prepare-for-PHP-6.html#extended -
Oliv' a écrit le 26/11/2005 :
j'attire d'ailleurs ton attention david sur cette ligne qui va avoir de grosses conséquences :
Return by Reference will errorBoth '$foo =& new StdClass()' and 'function &foo' will now raise an E_STRICT error.
avec ça je suis bon pour parcourir tout le code de mes projets... Super...
-
okworld a écrit le 27/11/2005 :
c'est clair, deja avec la version 5.0.x il fallait revoir une bonne partie du code;
la ou je bosse par exemple l'intranet ne fonctionne qu'avec php4 et je sens que ca sera la galere pour le mettre a jour. Cependant il ne faut pas nier que php5.x offre de belles choses et je pense qu'il vaut le coup de faire un petit effort :) -
fabmatt a écrit le 27/11/2005 :
ouch comme ça va faire mal...je sens que les développeurs php vont avoir du mal a suivre
-
Oliv' a écrit le 28/11/2005 :
Oui, ça vaut le coup. Le problème étant que nous avons le "cul entre deux chaises". Je suis arrivé à convaincre ma société de développer en php et non en .Net. Cela étant dit, la durée de vie des applications que nous développons se comptent en année. C'est toujours la même problématique avec php : la migration d'une version à une autre pose beaucoup de soucis, là où il suffit de mettre le framework à jour avec .Net. L'install de php n'a rien de compliqué, c'est la balance entre version majeure de php et compatibilité descendante des sites qui est difficile.
Et puis encore une chose, je me lance dans des projets PHP5 / MySQL 5, vous en avez vu beaucoup vous des hébergeurs proposant ce système? Perso, obligé de chercher à l'étranger pour trouver... -
pilgrim a écrit le 28/11/2005 :
Disons que PHP5 en lui-même est une très bonne chose ; ce que je trouve dommage c'est la rapidité avec laquelle les versions se succèdent mais surtout le fait que d'une version majeure à l'autre, il y a toujours quelque chose de cassé. Quand on développe pour soi, on ronchonne un coup et on met à jour mais quand, dans une entreprise, on développe pour tout un tas de clients, le passage à une nouvelle version telle que PHP5 peut s'avérer problématique : en effet, le client ne va pas payer pour qu'on reprenne ses scripts pour mettre à jour son site. Une heure de développement en entreprise a un coût non négligeable et il est impensable de reprendre un à un des scripts qui fonctionnent parfaitement en PHP4 tout cela pour mettre à jour l'ensemble d'un serveur de prod.
-
okworld a écrit le 28/11/2005 :
oui, malheureusement ce que vous dites est veridique.
Mais comme tu l'as si bien dit ds ton post la guerre des languages n'a pas epargne PHP. Je pense que php a ete depuis le debut "mal concus" et je parle specialement du modele objet. Lorsque le temps est venu de le mettre a niveau eh ben la ils se sont retrouve coinces ! donc il fallait tout reprendre depuis le debut et "reprendre tout depuis le debut" veut dire tout casse et foutre en l'air la compatibilite descendante. sauf que si cette reconstruction aurait ete faite lors de la transition php3 => php4 cela aurait ete beaucoup moins douleureux vue que le nombres d'utilisateurs (pro) et applications n'etait pas tres eleve comme c'est le cas a present.
Que faire maintenant face a cette situation ? subir !? -
okworld a écrit le 29/11/2005 :
ca devient n'importe koi la, les betas et autres RCs servent a koi alors ?! vivement le passage vers RubyOnRails !
-
okworld a écrit le 10/12/2005 :
a lire
phplens.com/[...]/221
Ajouter un commentaire
Il n'est plus possible de réagir à cette entrée directement mais si vous pensez que votre intervention peut être intéressante, envoyez-moi votre commentaire, je l'ajouterai ici en votre nom.