IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Actualité : PHP 5.3.0 final est sorti
Avec des améliorations de POO et de performances, l'avez-vous essayé ?

Le , par RideKick
71 commentaires

0PARTAGES

1  0 
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 !
Citation Envoyé par Yogui Voir le message
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.
Citation Envoyé par Yogui Voir le message
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 !
Citation Envoyé par Yogui Voir le message
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

71 commentaires
Commenter Signaler un problème
berceker united
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 07/11/2008 à 11:26
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.
1  0 
kaymak
Avatar de kaymak
Membre émérite https://www.developpez.com
Le 07/11/2008 à 12:09
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.
1  0 
goodpz
Avatar de goodpz
Membre confirmé https://www.developpez.com
Le 22/11/2008 à 14:35
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.
1  0 
metagoto
Avatar de metagoto
Membre éclairé https://www.developpez.com
Le 18/06/2009 à 21:52
Citation Envoyé par Yogui Voir le message
JavaScript permet de faire de belles choses, mais le code d'une application JS est souvent qualifiable d'illisible à mon avis...

L'un des problèmes de ce que tu proposes est que le code suivant serait syntaxiquement permis :
Code : Sélectionner tout 
ma_fonction()()()()()[6]()[2]->appel()[1];
Si ce code a du sens, pourquoi pas ?
C'est juste une question de cohérence, les développeurs étant libre d'implémenter leurs trucs comme ils le veulent! Dans un tel cas, ce développeur me paraîtrait bien sur de lui

Voici ce que l'on devrait faire actuellement pour arriver à la même chose:
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
$tmp1 = ma_fonction();
$tmp2 = $tmp1();
$tmp3 = $tmp2();
$tmp4 = $tmp3();
$tmp5 = $tmp4();
$tmp6 = $tmp5[6];
$tmp7 = $tmp6();
$tmp8 = $tmp7[2]->appel();
/*$result = */$tmp8[1];
Quitte à avoir le choix, je préfère me passer des 8 variables temporaires et dérouler le code dans un pur style à la C, ce dont est issu php! Je me répète, les features sont là, il faut juste être cohérent maintenant, ce qui n'a rien à voir avec l'offuscation ou même "l'ésotérisme" que l'on peut apporter aux codes
1  0 
berceker united
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 28/07/2009 à 16:16
Citation Envoyé par gannher Voir le message
Ah alors ce n'est utile que pour les très gros projets ?
Parce que même dans un framework par exemple, je n'en vois pas encore l'utilité.
Je suis en train de faire mon propre framework en php et j'ai beau réfléchir, je ne croule pas encore sous le nombre de classes ^^ .

L'utilisation des espaces de nom doit se limiter pour les gros projets métiers sans doute.
Non, c'est tout aussi utile dans une framework et je dirais même que c'est là ou c'est le plus utilisé.
1  0 
metagoto
Avatar de metagoto
Membre éclairé https://www.developpez.com
Le 28/07/2009 à 21:17
Citation Envoyé par gannher Voir le message
L'utilisation des espaces de nom doit se limiter pour les gros projets métiers sans doute.
Je n'irai pas jusque là. A mon avis, dès qu'un projet, aussi petit soit-il, est succeptible de manipuler différents composants provenant de différentes sources, alors les espaces de noms sont conseillés.

Dans la pratique, les auteurs de libraries ont pris l'habitude de préfixer leurs classes et fonctions de manière à "émuler" un espace de nom qui leur est propre. Genre Zend_Blah, sfBlah...

Maintenant, avec php 5.3, on devrait théoriquement se passer de ses préfixes archaïques en utilisant, au minimum, un niveau d'espace de nom: Zend\, sf\ (ou symfony\) etc.
1  0 
Yogui
Avatar de Yogui
Rédacteur https://www.developpez.com
Le 29/07/2009 à 13:25
Salut

Pour info, la surcharge de méthode d'une classe parente est soumise à certaines contraintes (bonnes pratiques POO) :

  • même nombre d'arguments obligatoires
  • même visibilité (public/protected/private)


C'est simplement l'implémentation POO par PHP qui le préconise. La réflexion est que si on change ces aspects d'une méthode, alors le polymorphisme n'est plus la même. Si j'ai une classe A et une classe B qui en dérive, je dois pouvois appeler les méthodes de B de la même manière que celles de A puisque ce sont des objets compatibles : si vous changez la visibilité de la méthode ou le nombre d'arguments obligatoires, alors ce n'est plus possible et vous cassez toute la conception OO de votre application.
1  0 
metagoto
Avatar de metagoto
Membre éclairé https://www.developpez.com
Le 05/08/2009 à 16:47
Quand php appelle les __autoload, le nom de la classe qui est passé en paramètre est un nom complètement qualifié (cependant, le premier '\' n'est jamais passé).
Exemple, si le namespace courant est machin\truc et que tu fais $a = new A; alors php va regarder si machin\truc\A existe. S'il ne trouve pas la classe, il appelle l'autoload avec machin\truc\A comme nom de classe.
Si machin était un alias pour, disons, autre\bidule, alors autoload recevra autre\bidule\machin\truc\A comme nom de classe.

C'est ce genre d'autoloading que j'utilise:
http://www.developpez.net/forums/d76...ng-namespaces/
Plusieurs autoloaders basés sur ce principe sont registrés auprès de spl_autoload_register(). En fait, une registration par racine de namespace:

Genre si j'ai un namespace framework (et possiblement des sous ramifications framework\blah\bleh..), j'aurais un autoloader pour framework, qui est un composant du framework.

Si j'ai un autre namespace myself\machin\truc, j'enregistre un autoloader similaire qui gère uniquement myself et ses descendants.

Je n'ai rien dans l'include_path parceque j'en n'ai pas besoins. Il y a un mapping directe entre les branches des namespaces et les répertoires du filesys. Je pense que c'est un bon compromis en terme de performance (aucun lookups) et de facilité d'utilisation.
1  0 
gene69
Avatar de gene69
Membre émérite https://www.developpez.com
Le 13/10/2010 à 22:30
La question est "que pensez vous de php5.3"?

ma réponse est que du bien !

  • d'abord je me moque des histoires de syntaxes compliquées, logiques ou pas (quoi que je fasse des fonctions anonymes depuis peu)
  • parce que ya plein de fonction qui n'étais pas native windows et qui le sont devenue
  • parce que j'ai eu 0 problème pour faire passer des scripts d'un moteur php 4.3 à 5.3.1, hormis la mode qui veut qu'on ne fait plus de magic quote ni de balise brève.
  • parce que j'ai trouver des trucs sympa comme __DIR__ et pour moi qui me limite a des syntaxes triviale, c'est génial.
1  0 
kaymak
Avatar de kaymak
Membre émérite https://www.developpez.com
Le 05/11/2008 à 19:54
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 ?
0  0 
Commenter Signaler un problème