Et pour ménager un peu le suspense, je vais donc commencer par vous parler très logiquement des modifications faites sur la version de développement, et que l'on pourra appelé peut être dans quelques mois PHP 5.4.
La modification plus importante concerne le paramètre de compilation--enable-zend-multibyte
, qui permettait à PHP de détecter les scripts au format Unicode et qui devait être explicitement activé lors de la compilation du langage.
Il a maintenant disparu et il est remplacé par la directive de configuration zend.multibyte
, accessible via le fichier php.ini
, et la détection des scripts encodés à l'aide d'Unicode est dorénavant activée par défaut.
J'avoue que cette modification m'effraye un peu, car j'ai déjà rencontré des problèmes, notamment au niveau des archives PHAR, lorsque ce paramètre de compilation était activé, sans avoir jamais pu en connaître ou en découvrir la raison.
J'espère donc que le fait que le mécanisme de détection automatique de l'encodage soit maintenant activé par défaut ne posera pas de problèmes.
Autre modification intéressante, effectuée suite à la requête #53427, les clefs associatives d'un tableau passé en premier argument de stream_select()
sont maintenant conservées.
Il faut cependant noter que cette modification ne pourra être effectuée dans PHP 5.3, pour des raisons techniques.
Par ailleurs, dans un registre plus modeste, les bugs #52854, #51901, #51003, #35547, #53377, #46587, #53352, #53403, #46587, #53304, #53407, #52501, #53409, #52327, #53420, #52828, #52656 et enfin #52202 ont été résolus.
Un bug a de plus été corrigé dans la révision 305754 sur la correction du bug #46587, et comme d'habitude, je n'ai pu m'empêcher de sourire à la lecture du commentaire associé :
Fixes the fix for bug #46587.
Et comme d'habitude, il y a le lot de petites optimisations diverses qui ne correspondent pas à un rapport de bug, sans oublier évidement les nettoyages effectués sur le code pour supprimer des alertes à la compilation ou bien pour respecter les conventions de codage.
Les affaires courantes étant maintenant expédiées, nous allons pouvoir maintenant rentrer dans le vif du sujet, à savoir ce qu'il se passe actuellement sur la liste de diffusion des contributeurs.
Plusieurs discussions, plus ou moins importantes, sont en cours et concerne à la fois le développement du langage et ses fonctionnalités.
Tout d'abord, une RFC visant à formaliser le processus de création d'une nouvelle version du langage a été proposée par un groupe de huit développeurs relativement influant au sein de la communauté des contributeurs.
Fraîchement accueilli dans un premier temps par les traditionalistes, il semble que la discussion évolue dans le bon sens et soit constructive, d'autant que cette RFC a reçu le soutient d'Andi Gutmans, l'un des deux créateurs du Zend Engine ainsi que celui de Lukas Kahwe Smith, l'ex monsieur formalisme de PHP puisqu'il a quitté le projet il y a maintenant quelques mois.
Il faut dire que les contributeurs peinent à sortir une version alpha de PHP 5.4 et que cette RFC arrive donc à point nommé.
Initialement prévue pour le 24 novembre, cette version alpha n'est toujours pas disponible, du fait d'un manque de consensus sur certaines fonctionnalités emblématiques de la prochaine version, comme le contrôle du type des arguments numériques lors d'un appel de fonction ou de méthode, la suppression des magic quotes
, la cassure de la compatibilité avec les versions antérieures ou bien encore sur une chose aussi basique que le numéro de la version.
De plus, les traits ne semblent pas encore être totalement opérationnels, car certain cas exotiques ne sont pas correctement gérés, et si la dernière version d'APC compile lorsqu'il est intégré dans le code de PHP, il n'est pas fonctionnel.
Bref, les contributeurs ne sont pas près de voir le bout du tunnel en ce qui concerne PHP 5.4, et cela d'autant plus que l'outil de gestion de version qui est utilisé par la communauté des développeurs, à savoir subversion, ne permet pas d'extraire facilement du trunk les fonctionnalités indésirables afin de générer cette fameuse version alpha.
Pierre Joye, également parmi les auteurs de la RFC relative au processus de création d'une nouvelle version du langage, a donc proposé de migrer de subversion vers un système de gestion plus adapté au processus de développement de PHP, j'ai nommé Git.
Là encore, la proposition a reçu un accueil mitigé, d'autant qu'il y a parmi les contributeurs des fans d'autres systèmes de gestion de version décentralisé similaire à Git, comme Mercurial.
Et contrairement à la précédente, cette proposition n'a pas reçu le soutien d'Andi, qui pense qu'il y a mieux à faire sur le projet actuellement.
Il est donc difficile de dire ce que tout cela va donner, mais les choses bougent, et de mon point de vue, plutôt dans le bon sens.
Parallèlement à ces discussions relatives au processus de développement, il y a également eu des débats au sujet des fonctionnalités du langage.
Ainsi, Felipe Pena, également partie prenante dans les RFC précédemment citées, a proposé de permettre l’accès aux propriétés et aux méthodes d'une instance de classe directement après son sa création, de la manière suivante :
<?php var_dump(new foo()->bar()->x); ?>
À contrario des précédentes, la RFC correspondante a reçu un accueil chaleureux d'emblée de la plupart des contributeurs, et elle semble bien partie pour être intégrée prochainement dans le trunk une fois que quelques détails syntaxiques auront été réglés.
Une RFC proposant de supprimer le mot-clef function
au niveau des déclarations de méthodes dans une classe a également été rédigée.
Une déclaration de méthode pourrait alors prendre la forme suivante :
<?php
class Foo
{
public bar()
{
echo "Hello World";
}
}
?>
Si elle a été plébiscitée dans un premier temps, elle est maintenant contestée, notamment par les traditionalistes, car si elle était acceptée, cela compliquerait la maintenance du code, puisqu'il serait beaucoup moins facile de détecter une déclaration de méthode au sein d'un projet, sans parler des problèmes que cela poseraient aux outils de développement.
Enfin, une RFC proposant l'implémentation d'accesseurs à la manière de C# a été proposée :
<?php
class TimePeriod
{
private $seconds;
public $Hours
{
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; }
};
}
?>
Pour le moment, les avis sont mitigés à son sujet, et même si elle était finalement acceptée, la fonctionnalité correspondante ne serait pas intégrée dans la prochaine version du langage.
La communauté des développeurs de PHP est donc en pleine ébullition suite à une série d'offensives du parti progressiste, ce qui est bien la preuve que le langage est bien vivant et dispose des ressources nécessaires pour évoluer dans le bon sens, n'en déplaise à ses détracteurs.
Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.
10 réactions
1 De metagoto - 01/12/2010, 09:04
Il y a eu pas mal de choses effectivement!
Et pour les annotations, quid du consensus, statu quo? (et caetera)
2 De mageekguy - 01/12/2010, 09:07
@metagoto : Je n'ai rien vu passé sur ce sujet sur les dix derniers jours.
Aux dernières nouvelles, on était très loin d'un consensus et il avait été proposé de voir cela après la sortie de PHP 5.4.
3 De Blount - 01/12/2010, 09:45
Merci bien pour ce rapport.
La syntaxe d'accès aux méthodes et aux propriétés directement après l'instanciation, c'est effectivement une amélioration intéressante.
Sinon, je me range du coté des progressistes au sujet de la suppression des fonctions comme les "magic quotes". C'est inutile et peut poser des problèmes lors du passage d'une configuration à une autre.
4 De Olivier Laviale - 01/12/2010, 10:09
Que de nouvelles ! Ça fait plaisir de voir que ça bouge.
Je suis assez sceptique quand au contrôle du type des arguments. Qu'est-ce qui va se passer pour 1 et "1" ? Si c'est pour se retrouver à caster à tout va comme en C, non merci. Je trouve le système actuel suffisant : tableaux, et objets.
Pourquoi pas tomber le "function", mais je préfèrerai avoir la possibilité de créer des tableaux comme "[1, 2, 3]" ou des objets anonymes à la Javascript.
Merci pour ces rapports qui sont plus intriguants que Dallas !
5 De MathRobin - 01/12/2010, 10:11
Tout d'abord, merci de ce point^^
J'avoue que j'apprends avec plaisir la suggestion d'implémenter les accesseurs à la façon C# (on parle de propriétés dans le monde Microsoft pour désigner cette façon de faire). Je trouve ça plus agréable à lire et surtout moins polluant dans la fenêtre "outline" d'un éditeur que les get()/set() classiques.
Pour ce qui est de virer le terme "function", quel est le but recherché? Ils veulent le virer juste pour le virer ou il y a une autre idée derrière? En soit, il n'est pas dérangeant. Je ne suis pas convaincu qu'on va gagner quoi que ce soit en perfos en le virant et ça ne change pas grand chose à la lisibilité. Par contre, je trouve un peu moisi l'argument qui dit que ça va provoquer des problèmes au sein des IDE. Ca ne change pas grand chose à la façon de déclarer une fonction et je pense que les développeurs derrière les IDE ne metteraient pas longtemps à corriger le tir à travers une mise à jour assez basique si ça devait être implémenté.
6 De mageekguy - 01/12/2010, 10:13
@MathRobin : En gros, le token T_FUNCTION est inutile dans ce contexte, donc c'est en soit, et de mon point de vue, une bonne raison de le supprimer.
Et apparemment, oublier le mot-clef
function
est une erreur fréquente et récurrente lors d'un développement.En terme de performance, l'incidence est nulle, effectivement.
C'est plus une question d'ergonomie du langage et de lisibilité qu'autre chose, ce qui fait dire aux détracteurs de cette proposition que c'est du
, suivant l'expression consacrée.7 De usul_ - 01/12/2010, 10:13
Je ne comprend pas la suppression du mot-clef
function
.Ca s'apparente à de la flemme pour moi et introduira une baisse de lisibilité du code.
En ce qui concerne les appels chainés, c'est sympa mais je vais avoir l'impression de faire du jquery :).
Je suis mitigé sur les accesseurs, le concept m'intéresse mais je sais pas encore trop quelle syntaxe de la RFC je préfère.
8 De Thierry - 01/12/2010, 10:48
Merci pour ce résumé très intéressant !
Dommage pour GIT... (même si en tant qu'utilisateur de PHP ça ne changera rien pour nous)
9 De Eric D. - 01/12/2010, 13:10
Ah OUI pour la dernière, c'est une des choses qui manque pour une vraie évolution du modèle objet qui ne demande pas de faire des get() et des set() partout.
10 De ronan - 01/12/2010, 22:50
La posibilité de chainer directement une méthode à l'appel me semble être une bonne idée, ça fera gagner quelques lignes de code de pouvoir initailiser et faire travailler l'instance sur une thème particulier dès le départ.
Quant à la suppression du terme function, oui pourquoi pas, c'est aussi selon le gout de chacun, c'est vrai que l'association des private, protected... à function est un peu rébarbative à l'écriture.