Discussion :

[RideKick]

PHP 5.3, la prochaine grande évolution du langage PHP, approche de la phase alpha 3 : http://wiki.php.net/todo/php53

MÀJ 30/06/2009 : Sortie de PHP 5.3 version finale !

Voici la sortie officielle de PHP 5.3 !
http://www.php.net/downloads.php
http://windows.php.net/download/

MÀJ 28/06/2009 : Le code source est tagué "5.3.0". Sortie de PHP 5.3 final confirmée pour le mardi 30 juin.

Johannes annonçait il y a quelques heures que PHP 5.3 est réellement prévu pour mardi, cette fois c'est la bonne.

Les builds pour Windows seront faits aujourd'hui (dimanche), puis testés par Pierre et ses collègues jusqu'à lundi soir. Si vous repérez un bug dans ce temps, faites-vous connaître

MÀJ 10/06/2009 : PHP 5.3 va bientôt sortir !

Le 11 juin : PHP 5.3 RC3
Jusqu'au 17 juin : corrections de bugs
Le 18 juin : PHP 5.3 RC4 s'il y a eu des commits depuis le 11 juin (pour info : il y en a eu )
Jusqu'au 24 juin : dernières vérifications de PHP 5.3 RC4
Le 25 juin : PHP 5.3 RC 4 devient PHP 5.3.0 final

Voici un aperçu des nouveautés :

L'une des évolutions majeures de la version 5.3 est l'ajout des espaces de noms, aka namespaces. Nous en avons discuté ici :
http://www.developpez.net/forums/d60...oms-php-5-3-a/

C'était une discussion animée. Le PHP Group lui-même a mis plus de trois ans (!) pour arriver à un accord sur le séparateur d'espaces de noms (le backslash). Nous en avons discuté ici-même :
http://www.developpez.net/forums/d63...-enfin-choisi/
Une autre fonctionnalité de PHP 5.3, quoique moins attendue dans la mesure où elle concerne des cas d'utilisation moins fréquents, concerne les "fonctions anonymes", aussi appelées "fonctions lambda" et souvent utilisées dans le contexte de "fermetures". Là encore, nous en avons parlé sur les forums :
http://www.developpez.net/forums/d57...ermetures-php/

Les Late Static Bindings (LSB) sont une fonctionnalité dont les frameworks vont être particulièrement friands.

La nouvelle méthode magique __callStatic(), équivalente à __call() pour les méthodes statiques.

Le pilote natif de MySQL pour PHP : mysqlnd, qui résoud tous les problèmes actuels de compatibilité de licence tout en améliorant les performances des extensions qui l'utilisent (MySQLi, PDO...).

Fichiers php.ini par utilisateur avec une syntaxe similaire aux fichiers ".htaccess" pour Apache httpd.

Le niveau d'erreurs E_DEPRECATED avertir le programmeur s'il utilise une fonctionnalité obsolète du langage.

Un "garbage collector" pour libérer la mémoire lorsque c'est nécessaire : cela rend PHP éligible pour des scripts à long temps d'exécution.

La syntaxe NOWDOC pour les chaînes est l'équivalent "guillemets" si on compare la syntaxe HEREDOC à des "apostrophes". Dans un cas, les chaînes spéciales sont interprétées (variables, \n, \t, etc.) mais pas dans l'autre.

Améliorations de la Standard PHP Library (SPL).

Une nouvelle extension de packaging, phar, permet de distribuer des applications entières sous la forme d'un fichier créé à l'aide d'un algorithme puissant de compression. Ce fichier peut être exécuté directement par PHP sans avoir besoin de le décomprimer.

Les versions compilées (officiellement) pour Windows le sont avec Microsoft Visual Studio 9 au lieu de Visual Studio 6, ce qui apporte de nettes améliorations de stabilité, performances, etc. pour ceux d'entre vous qui développent sous Windows (et visiblement, vous êtes une majorité).

etc.


De nombreux frameworks PHP ont déjà prévu un plan de migration vers PHP 5.3 pour leur prochaine version majeure (principalement à cause des espaces de noms)

Qu'en dites-vous ? Qui d'entre vous a déjà essayé PHP 5.3 alpha, qui prévoit d'essayer les versions bêta ?

[grunk]

Pour les type mime ya une extension PECL qui le fait déjà très bien

Fichiers php.ini par utilisateur avec une syntaxe similaire aux fichiers ".htaccess" pour Apache httpd.

Ca c'est plutôt sympa , ça va sans doute ouvrir quelques possibilité au niveau des hébergé sur mutu.

cela rend PHP éligible pour des scripts à long temps d'exécution.

Tout dépend ce que l'on appelle à long temps d'exécution , mais je reste convaincu que PHP n'est pas adapter pour des traitement lourd. D'autres langage compilés le font tellement plus rapidement que je vois pas trop l'intérêt.

Perso comme à chaque fois j'attendrais une release stable avant de tester quoi que ce soit. J'attends rien de spécial de cette nouvelle version. Les namespace sont certes une jolie nouveauté , mais on fait sans depuis bien longtemps sans pour autant que cela pose de réels problèmes (pas à moi en tout cas ^^ ).

[kaymak]

Concernant les PHAR, est ce que c'est du code compilé inside ? à la manière de bcompiler.
http://fr.php.net/manual/fr/phar.using.php

Ou est ce que se sera vraiement de la gestion de librairie / paquet ?

Ce qui est déjà super cool en soit.

Et quid de l'autoload ?

[Yogui]

L'idée de phar est de gérer les scripts PHP à l'intérieur d'une archive phar exactement comme si c'étaient des scripts. Le packaging par défaut n'encrypte pas les scripts, en fait je ne sais pas si phar sait encrypter ou précompiler les scripts. Ce n'est de toute manière pas son objectif

L'auteur de phar a testé son extension en prenant phpMyAdmin. Cela semble fonctionner sans problème, et l'autoload ne pose pas de souci.

[berceker united]

Phar, mmmhhh ça a l'air bon ça. En fait, c'est équivalent à une package java.
C'est plus facile pour le déploiement et surtout pour les gros framwork, ainsi le système de fichier du serveur ne sera pas sollicité en faisant 36 include dans un page ou utiliser un autoload super balaise.

[Yogui]

Attention, phar ne doit pas être perçu comme une solution pour améliorer les performances. Ce n'est pas l'objectif.

Si tu fais un paquetage phar, en effet le serveur ne charge pas autant de fichiers. Mais si tu souhaites améliorer les perfs, une extension comme APC répondra bien mieux à tes attentes. Note tout de même que phar est compatible avec APC

Concernant l'autoload, il n'y a rien de simplifié puisque c'est géré comme un flux, il y a donc encore la notion de fichiers à l'intérieur d'une archive phar. Ce n'est pas de la concaténation de fichiers, c'est du packaging.

[kaymak]

Par contre question déploiement, gestion par package/module, c'est top.
Après il faudrait que bcompiler fonctionne correctement avec et se sera parfait.

M'enfin globalement elle est bien cette release, on sent que le passage à l'objet est fait et que maintenant sa évolue pour se perfectionner.
Il ne resterait plus qu'à avoir une doc décente pour la SPL.

[berceker united]

Attention, phar ne doit pas être perçu comme une solution pour améliorer les performances. Ce n'est pas l'objectif.

Si tu fais un paquetage phar, en effet le serveur ne charge pas autant de fichiers. Mais si tu souhaites améliorer les perfs, une extension comme APC répondra bien mieux à tes attentes. Note tout de même que phar est compatible avec APC

Concernant l'autoload, il n'y a rien de simplifié puisque c'est géré comme un flux, il y a donc encore la notion de fichiers à l'intérieur d'une archive phar. Ce n'est pas de la concaténation de fichiers, c'est du packaging.

Oui j'avais compris que ça n'améliore pas les performances c'est améliore juste le parsage de fichier. Par contre, c'est utile pour le déploiement surtout quand c'est une framework ou autre utilisant un gros ensemble de fichier objet.

[Yogui]

Une idée de la date de sortie de cette version de PHP?

La version alpha 3 (avec au moins les espaces de noms finalisés) est prévue pour mardi 18 novembre. Je ne crois pas qu'il y ait d'alpha 4. Suivront quelques versions bêta (nombre encore non décidé), puis la version finale.

[Yogui]

Un vote vient d'être effectué sur les listes internes afin de décider de plusieurs fonctionnalités :

Le vote : http://marc.info/?l=php-internals&m=122651740720233&w=2
Les résultats : http://marc.info/?l=php-internals&m=122684228317217&w=2

Retirer ext/hash par défaut
=> Conserver ext/hash activée par défaut

Retirer ext/mhash
=> Oui

Déconseiller ereg*
=> Déconseiller ext/ereg et retirer dans PHP 6

Ressources constantes
a) Déconseiller les ressources constantes (principalement utilisées pour émuler STDIN et similaires)
b) Simplement lancer E_STRICT
c) Documenter tel quel
=> Documenter tel quel

Conserver ext/phar activée par défaut dans 5.3 ?
=> Oui

Conserver ext/sqlite3 activée par défaut dans 5.3 ?
=> Oui

Activer mysqlnd par défaut ?
=> Ne pas activer par défaut puisqu'il n'y a pas assez de support (maintenance) pour ajouter quoi que ce soit

Activer ext/mysql, mysqli et pdo_mysql par défaut ?
=> Non puisque la proposition précédente a été rejetée

La mise en tampon de la sortie devrait-elle réécrire MFH ?
=> Non, vote pas assez clair

Nettoyage de MFH dans ext/mcrypt (HEAD)
a) revert in HEAD
b) MFH to 5.3
=> Derick est le mainteneur d'ext/mcrypt et il s'oppose à la modification à cause du manque de tests, ainsi y a-t-il des volontaires pour écrire des tests ?

Pour rappel, "déconseiller" signifie lancer une erreur de niveau E_DEPRECATED.

[goodpz]

Ca va être un peu spécial de s'adapter aux nouveaux namespaces avec l'arrivée du séparateur "\". Mais bon, je suis convaincu que c'est la meilleure solution, eu égard aux contraintes en vigueur

Le late static binding, les fonctions anonymes avec closures, ça va être top.

[Yogui]

Voici la troisème version alpha de PHP 5.3 :
http://qa.php.net/
http://windows.php.net/qa/

[s4mk1ng]

je penses que ce serait bien que PHP évolué,ça fait depuis trop longtemps qu'on est sur la même version

[kaymak]

je penses que ce serait bien que PHP évolué,ça fait depuis trop longtemps qu'on est sur la même version

En même temps mieux vos qu'ils prennent un peu de temps pour pondre une 5.3 correct plutôt que de refaire comme pour la 5.0 qui sincèrement nécessitait d'attente la 5.1/5.2 pour être utilisable sereinement.

[Yogui]

Pour info, PHP 5.3 est en version Release Candidate

[Talus]

Hello,

Je suis un peu à la bourre (juste 3 mois), mais je souhaite juste signaler une erreur... La syntaxe NOWDOC n'est pas aux guillemets si on compare la syntaxe HEREDOC aux apostrophes, mais l'inverse. Aucune analyse n'est effectuée...

Et aussi, la RC3 pointe le bout de son nez d'ici le 11 juin... Et les RM espèrent que ce sera la Gold Release Candidate ("RC Finale")

[kaymak]

..

Et aussi, la RC3 pointe le bout de son nez d'ici le 11 juin... Et les RM espèrent que ce sera la Gold Release Candidate ("RC Finale")

ouep, j'ai vu hier soir qu'ils allaient intégrer un gc pour suppimer les réf circulaires en mèmoire
Se serait encore mieux si il le portait sur la 5.2 aussi... Mais bon.

[Yogui]

Salut

Comme le dit Talus ci-dessus, PHP 5.3 ne va plus tarder :

June 10th:
We package RC3, until then only critical
build fixes and similar which have to go in the RC, after review
(highlight me on IRC, mail etc.)

June 11th:
RC3 will be released

June 11th-17th
A small window for critical fixes and again please check beforehand as
we don't want to introduce any new bugs that late in the game.

June 17th
In case there were commits after RC3 we will package a RC 4 on
Wednesday next week

June 18th
If needed publish RC4

June 18th - June 24th
The plan is to repackage RC4 as 5.3.0 final in the beginning of the
week of the 21st without any further changes so we can test the
packages. In case something critical, unexpected, pops up please
notify us asap.

June 25th 2009
Release PHP 5.3.0 final.

Traduction :

• Le 11 juin : PHP 5.3 RC3
• Jusqu'au 17 juin : corrections de bugs
• Le 18 juin : PHP 5.3 RC4 s'il y a eu des commits depuis le 11 juin (pour info : il y en a eu )
• Jusqu'au 24 juin : dernières vérifications de PHP 5.3 RC4
• Le 25 juin : PHP 5.3 RC 4 devient PHP 5.3.0 final

À bientôt, donc

[Jérémie A.]

Bien bien bien ca arrive

[kaymak]

o fait quid de la compat. des scripts développés en php 5.2, beaucoup de changement en perspective, ou très peu ?