PHP 5.5 disponible

PHP 5.5 introduit le support des générateurs, du block Finally et de Zend Opcache
la version finale met fin à la prise en charge de Windows XP

Après plusieurs mois de développement, la communauté en charge de PHP est fière d’annoncer la sortie de la version 5.5, qui apporte un nombre important de nouvelles fonctionnalités au langage de programmation Web.

http://www.developpez.com/public/images/news/php.png

La nouveauté tant attendue est l’intégration du mot clé finally. finally permet d'éviter au développeur d'écrire un code de nettoyage lorsqu'une exception non manipulable se produit.

Les développeurs apprécieront la prise en charge des générateurs. Les générateurs sont un moyen simple et puissant de créer des itérateurs. L’introduction des générateurs dans PHP va permettre aux développeurs d’implémenter des itérateurs sans avoir à écrire beaucoup de code.

Le support des générateurs s’accompagne de l’introduction du nouveau mot clé « yield », qui permet d’implémenter un itérateur. Ce mot clé peut être utilisé suivant trois syntaxes différentes (yield, yield $value, yield $key => $value).

Les boucles foreach supportent désormais les listes et les clés non scalaires pour les itérateurs. L’ajout d’array_column permet de retourner une colonne dans un tableau multidimensionnel.

La nouvelle API de hachage des mots de passe permettra aux développeurs et administrateurs de stocker en toute sécurité les mots de passe. En une seule ligne de code, les développeurs pourront générer un mot de passe chiffré en utilisant bcrypt.

$hash = password_hash($password, PASSWORD_DEFAULT);

L’intégration de Zend Opcache extension est également au rendez-vous. Cette fonctionnalité permet de charger plus rapidement les pages PHP en améliorant les performances du bytecode généré par l’interpréteur de code source PHP.

Côté compatibilité, cette version met fin au support de Windows XP et Windows 2003.

:fleche: Télécharger PHP 5.5

Source : le site du projet


Et vous ?

:fleche: Que pensez-vous de ces nouveautés ? Laquelle attendiez-vous le plus ?

:fleche: La fin du support de Windows XP est-elle précoce ?

L'API de mot de passe est réellement intéressante puisqu'elle fournit enfin un moyen robuste et simple de hasher des mdp. On va peut être arriver à bout du md5 :P

Le déférencement des tableau/chaine de caractères est également sympa , mais à utiliser avec parcimonie si on veux pas se retrouver avec un code dégeulasse.

Enfin l'ajout d'un cache d'opcode en standard est un vrai plus !

Les générateurs par contre je vois toujours pas l'intérêt, je suis un peu le truc depuis l'apparition de la RFC et j'ai juste l'impression que c'est là parce ça se fait dans d'autre langage et que c'est la mode.
Si quelqu'un à un cas concret d'utilisation , ou le générateur surpasse les solutions classiques je suis preneur.

Ah ! et pour finir la possibilité de faire if(empty(maFonction())) , ca, ca va changer ma vie ^^ (sous réserve que j'ai le temps de refaire du php >< )

En tant que développeur ASP.Net ces ajouts devraient etre les bases de ce langage depuis longtemps.
En tout cas cela permettra de développer plus rapidement, plus proprement et éviter quelques erreurs de jadis :ccool:

Citation:

---

Envoyé par grunk

Les générateurs par contre je vois toujours pas l'intérêt, je suis un peu le truc depuis l'apparition de la RFC et j'ai juste l'impression que c'est là parce ça se fait dans d'autre langage et que c'est la mode.
Si quelqu'un à un cas concret d'utilisation , ou le générateur surpasse les solutions classiques je suis preneur.

---

D'après ce que j'ai lu ici :

http://fr2.php.net/manual/fr/languag...s.overview.php

Il semblerait que ce soit une question de gain de mémoire et de temps d'exécution concernant les tableaux à traiter dans des boucles. En effet, un tableau de données hyper gros va prendre beaucoup de place/de temps pour le traiter de façon classique, à savoir :

1. je génère mon tableau hyper gros (conso de mémoire et temps +++)
2. je le passe dans la boucle pour faire le traitement

Le générateur va permettre de traiter le tableau au fur et à mesure qu'il est généré. Du coup pas besoin de stocker toutes les données avant de les traiter : on les génère et on les traite à la volée. A priori ça deviendrait :

1. je génère une ligne de mon tableau
2. je la traite
3. je recommence

C'est utile lorsque tu as une méthode qui te retourne un ensemble de valeur.

Par exemple aujourd'hui lorsque tu veux utiliser une méthode qui retourne une liste, tu dois d'abord construire ta liste, puis retourner ta liste pour l'afficher avec un foreach par exemple.

Si tu te sers très souvent de ta liste (par exemple un attribut) ok, par contre si c'est pour un affichage unique, tu auras perdu ton temps à construire la liste dans un premier temps, puis à la faire défiler dans ta boucle pour l'afficher.
Dans ce cas il y a gain de mémoire et gain de temps.

Pour certains traitements lourds, le yield() va amener énormément de simplification. Pour des questions de dépassement de mémoire, j'ai eu à émuler l'équivalent d'un yield() en PHP 5.3+ et ben je peux vous garantir que c'est moche :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

$start; $end;   $yield = function() use (&$start, &$end) { static $i = -1; return (++$i <= ($end - $start)) ? $i + $start : false; };   $start = 15; $end = 20; $data = array();   while ($v = $yield()) { $data[] = $v; }   // ou   $yield = function($start, $end) { static $i = -1; return (++$i <= ($end - $start)) ? $i + $start : false; };   $data = array();   while ($v = $yield(15, 20)) { $data[] = $v; }

---

On a l'équivalent d'un foreach() sans la consommation mémoire.

Bref, ça répond au besoin avec les moyens du bord, mais faut avouer que c'est une béquille bien crade...

On attends surtout et toujours une implémentation complète d'Unicode... sans ce support PHP ne pourra et ne peux plus évoluer.

A tout ceux qui ont fait du traitement de chaîne de caractères un combat!

:cry:

Un développeur Php m'a fait comprendre hier que du coté Objet.
Php n'a plus rien à envié à JAVA. Et apparemment PHP a même déjà dépassé Java.
Je ne connais pas l'évolution de PHP mais j'etais très sceptique

Citation:

---

Envoyé par ygyongy

On attends surtout et toujours une implémentation complète d'Unicode... sans ce support PHP ne pourra et ne peux plus évoluer.

A tout ceux qui ont fait du traitement de chaîne de caractères un combat!

:cry:

---

Python est unicode et pourtant si on fait

Code:

---

1 2 3

>>> len('ééé') 6

---

C'est bizarre non

Avec PHP, il suffit de faire

Code:

---

mb_strlen('ééé');

---

ce qui donne 3

Citation:

---

Envoyé par matios

Python est unicode et pourtant si on fait

Code:

---

1 2 3

>>> len('ééé') 6

---

---

Comment fais-tu du coup en Python pour parcourir ton tableau de caractere? :ouin: Dois tu faire des vérifications pour chaque index?

J'ai développé plusieurs sites Web traduits dans plusieurs cultures, a vrai dire l'encodage c'est surtout embettant lors des export/import de données.
Par contre en France beaucoup de sites Web (et parmis les plus utilisés) n'utilisent pas les regles de base de l'encodage, du moins je le remarque tres souvent dans beaucoup de pages.
Si vous etes intéressé je vous conseille de lire cet article: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Pour les développeurs PHP qui connaissent le .Net le mot-clé yield sera plus que le bienvenu :ccool:

J'utilise énormément PHP pour faire des batchs d'extraction & alimentation / démons / multithread & multiserver etc...

Et dans certains cas même sans que l'on sache pourquoi (isref == 0 & refcount == 0) la mémoire à tendance à monter très haut sans compter les fuites mémoires toujours présent en 5.4 dans certains cas.

Pour ma part yield va vraiment changer ma vie, et c'est LA fonction que j'attendais avec impatience, ce qui va me permette d'éviter de faire de gros hook bien dégeu comme j'étais obliger de le faire jusqu'à présent !

Citation:

---

Envoyé par matios

Python est unicode et pourtant si on fait

Code:

---

1 2 3

>>> len('ééé') 6

---

---

En Python 2 il faut préciser que c'est une chaîne Unicode :

Code:

---

1 2 3

>>> len(u'ééé') 3

---

Citation:

---

Envoyé par bruneltouopi

Un développeur Php m'a fait comprendre hier que du coté Objet.
Php n'a plus rien à envié à JAVA. Et apparemment PHP a même déjà dépassé Java.
Je ne connais pas l'évolution de PHP mais j'etais très sceptique

---

Pas vraiment d'accord.

Le problème principal est que l'on peut coder proprement en PHP, là où l'on doit coder proprement dans d'autre langage. (cast automatique, typage faible, fonction qui peut retourner plusieurs type... etc..)

Sortie de PHP 5.5.1

L’équipe de développement du projet PHP vient d’annoncer sur son site la disponibilité immédiate de PHP dans sa version 5.5.1. Il s’agit pour cette version d’une répercussion des bogues déjà identifiés dans la déclinaison 5.3, notamment la correction d’une vingtaine de bogues et de la vulnérabilité de sécurité concernant le parseur XML. Nous avons donc comme améliorations pour cette nouvelle Release :

• l’autorisation de la compilation de PDO_OCI avec les librairies clientes de Oracle 12c ;
• l’absence de la page « Man » pour php-cgi ;
• la levée d’un E_WARNING pour une chaine hexa invalide dans la fonction hex2bin() ;
• la compatibilité de OPcache avec LiteSpeed SAPI ;
• la correction du bogue de la fonction strftime() qui tourne une chaîne de caractère de longueur insuffisante pour des locales (multibyte locales) ;
• l’ajout d’un argument optionnel create_sid() pour les fonctions session_set_save_handler(),SessionHandler et new SessionIdInterface ;
• etc.

Avec ce nombre élevé de bogues et de vulnérabilités identifiés et corrigés, les développeurs utilisant la branche 5.5 de PHP sont invités à migrer rapidement vers cette nouvelle version.

La liste complète des changements dans cette version est consultable sur ce lien

Pour télécharger : PHP.5.5.1

Source : site officiel du Projet PHP