Cependant, avant de rentrer dans le détail de ces propositions, je vais, comme d'habitude, vous présenter les principales modifications subies par le trunk au cours de la période qui vient de s'écouler.
Tout d'abord, les bugs #52609, #52654, #52407, #52655, #52655, #52674, #52681, #52614 et #52699 ont été corrigés.
De plus, le comportement de la fonction array_combine()
a été modifié, conformément à la demande #34857.
Cette dernière renverra donc dorénavant avec la prochaine version majeure du langage un tableau vide lorsqu'elle recevra deux tableaux vides en argument, au lieu de renvoyer le booléen false
et de générer une erreur de type E_WARNING
.
Le reste des modifications concerne notamment le module FastCGI, aka FPM, qui a été quelque peu optimisé et qui supporte maintenant les fonctions apache_child_terminate()
, getallheaders()
, apache_request_headers()
et apache_response_headers()
.
Et bien évidement, il y a eu le lot habituel de corrections visant à nettoyer le code et à faciliter la compilation.
C'est donc clairement sur la liste des contributeurs, internals@, qu'il faut aller chercher les informations croustillantes
.
Et il y en a eu, mais pas forcément croustillante dans le bon sens du terme.
Tout d'abord, il y a eu un énorme débat autour des contrôles effectués par PHP lors d'un héritage de classe.
En effet, ce dernier, conformément au principe de substitution de
Liskov, refuse, si le niveau d'erreur E_STRICT
est activé, qu'une méthode d'une classe fille surchargeant une méthode d'une classe parente dispose d'un nombre d'arguments inférieur.
Dans ce cas de figure, le langage génère alors une erreur E_STRICT
, ce qui ne semblait pas du goût de tout le monde.
Il y a donc eu une discussion assez longue sur le sujet expliquant ce fameux principe et finalement, il semble que la situation soit maintenant claire et acceptée.
Il y a également eu une proposition visant à ajouter deux constantes à PHP, E_NONE
et E_EVERYTHING
.
E_NONE
, comme son nom l'indique, a pour but de désactiver complètement la gestion des erreurs, et correspondrait donc à error_reporting(0).
E_EVERYTHING
permettrait quand à elle l'activation de la gestion d'erreur à son niveau le plus élevé.
Autant le dire immédiatement, cette proposition n'a pas suscité un débat très intéressant.
En effet, si quelques réponses ont été intéressantes, comme celle visant a ajouter en plus E_DEVELPEMENT
et E_PRODUCTION
, à la manière de ce que fait Apache, la plupart ont été pour le moins ironiques, puisque certain ont proposé E_ALL_AND_I_REALLY_REALLY_REALLY_DO_MEAN_ALL
et E_CHUCK_NORRIS
.
En conséquence, il y a peu de chances de voir arriver ces constantes dans la prochaine version du langage, du moins pour le moment.
Enfin, il y a également un débat autour des annotations, suite à la proposition d'une solution technique par Pierrick Charron faisant suite à la RFC correspondante.
Pour simplifier, les annotations sont des méta-données, qui peuvent être utiliser afin de documenter ou manipuler le code.
La prochaine version majeure de PHP est donc susceptible de les supporter, de la manière suivante :
<?php
class TODO extends ReflectionAnnotation
{
const SEVERITY_CRITICAL = 1;
const SEVERITY_IMPORTANT = 2;
const SEVERITY_TRIVIAL = 3;
public $value;
public $severity = self::SEVERITY_IMPORTANT;
}
[TODO("I need to implement this class", severity=CustomAnnotation::SEVERITY_CRITICAL)]
class Test {}
[TODO("Review this one")]
class Test2 {}
?>
Il est ensuite possible de récupérer les informations véhiculées par les annotations à l'aide des classes de reflexion :
<?php
$class = new reflectionClass('Test');
var_dump($class->getAnnotations());
/*
array(2) {
["TODO"]=>
object(TODO)#%d (1) {
["value"]=>"I need to implement this class"},
["severity" => 1
}
}*/
?>
Les contributeurs sont donc en train d'étudier cette solution afin de la valider et les choses semblent avancer rapidement.
En effet, il y a bien quelques remarques, notamment sur le fait de recourir à un objet pour définir les annotations, mais rien de bien sérieux, et de plus, cette solution ne pose aucun problème de compatibilité avec l'existant.
Pour terminer, il y a eu également un message courageux signalant que le portage du threading sous Windows au sein de PHP avait été réalisé, pour faire suite à son implémentation sous UNIX.
Cependant, ce message n'a suscité aucune réaction au niveau des contributeurs.
Il faut dire que Dieu Rasmus Lerdorf clame haut et fort depuis des années que le threading ne présente aucun intérêt au niveau de PHP, et que la communauté des contributeurs soutient mordicus que c'est impossible à réaliser techniquement au niveau du Zend Engine...
Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.
10 réactions
1 De metagoto - 30/08/2010, 23:04
Le post de Stas Malyshev dans internals "inheritance check too strict?" m'a fait sourire quand je suis tombé dessus il y a quelques jours. Un ancien de Zend Technologies qui découvre ce comportement de php pourtant bien connu. Autrefois, Stas aurait envoyé bouler n'importe quel utilisateur de php qui aurait daigné lancer ce sujet dans la mailing list. Les rôles seraient-ils inversés!?
Suis-je le seul à trouver ridicules des annotations du style [TODO("I need to implement this class")] ? Cela revient à utiliser les annotations comme de simples commentaires. Il y a un impacte sur les perfs et la mem car la phase de compilation parse et store toutes ces infos. Heureusement, d'après ce que j'ai compris, la représentation objet est construite de manière lazy (lors de la première utilisation). Mais quel est l'intérêt d'avoir ces infos au runtime? C'est d'un ridicule!
Je ne dis pas que les annotations en général sont superflues, je trouve juste que cet exemple du TODO (avec le severity lol), qu'on retrouve dans la mailing, n'est vraiment pas bien choisi.
2 De Yacodo - 31/08/2010, 02:01
Première fois que je découvre les annotations en développement, et l'exemple fait vraiment peur, de la mémoire contre un TODO, non merci. Mais le RFC donne des voies tout de même plus intéressantes, même si ils n'ont en tête que de la configurations/documentations, ce qui existait déjà avant. On va juste se retrouver avec un parseur un poil plus lent pour des fonctionnalités utilisées par une minorité.
La discussion sur les constantes m'a doucement fait sourire, surtout le E_ALL_AND_I_REALY_REALY_REALY_DO_MEAN_ALL, ça a au moins l'honneur de reflété une nouvelle prise de conscience sur les incohérences au sein du PHP Group, dommage pour E_CHUCK_NORRIS qui ne verra jamais le jour, pourtant c'était très prometteur.
Annotations, __invoke, threading... Chacun trouve une fonctionnalité utile une fois qu'il en n'a le besoin... Suffit juste que la majorité l'emporte donc, et pour le threading, c'est pas encore gagné.
3 De mageekguy - 31/08/2010, 08:50
@metagoto : Les annotations ne sont effectivement pour moi que des commentaires exploitables par le code, et j'avoue qu'avoir un parsing des commentaires à la place de \reflectionAnnotation n'aurait pas été pour me déplaire.
Et oui, à la relecture, l'exemple que j'ai choisi n'est pas effectivement très pertinents, ce qui est assez marrant car lors de la rédaction du billet, je me suis dis que c'était de loin le meilleur exemple de mise en œuvre que j'avais vu pour le moment...
Maintenant, en plus de la description de ce qu'il y a à faire et du niveau de criticité, il est possible d'imaginer l'ajout d'un numéro de ticket, du nom du développeur en charge de réaliser le travail, d'une date limite de réalisation, d'un nombre de jours alloués (eerrrrkkk), etc.
Il suffirait ensuite d'écrire le script PHP qui va bien pour obtenir une photographie de ce qu'il reste à faire sur le code, par qui et pour quand, plus simplement qu'à grand coup de
grep
et autres joyeusetés.Typiquement, ce genre d'exemple est pertinent dans le cadre d'un outil du type de phpUnderControl.
4 De MathieuROOBIN - 31/08/2010, 09:43
Les annotations ne devraient pas être autre chose que des commentaires à destinations par le serveur. En .Net, on peut mettre des annotations sur les méthodes de tests pour indiquer au compilo qu'il doit prendre la méthode en mode debug mais pas en release.
Pour les TODO, les commentaires classiques ça sert justement à ça.
Je n'ai pas saisi la différence entre le E_NONE et juste mettre display_errors à Off. Quelle différence également entre E_EVERYTHING et E_ALL, déjà présente? ça m'a l'air d'être soit un gros troll soit un gros noob ce type.
5 De mageekguy - 31/08/2010, 10:30
@MathieuROOBIN : E_NONE = display_errors(0) et E_EVERYTHING = display_errors(E_ALL | E_STRICT).
Le but est d'aider ceux qui ne maîtrise pas les masques de bits à s'en sortir.
Un nivellement par le bas, en quelque sorte...
6 De Ivan Enderlin - 31/08/2010, 10:51
Hey :-),
Les annotations sont un moyen d'ajouter de l'information à un algorithme (ou programme). Ces informations sont nécessaires dans des cadres particuliers, comme le test ou la preuve, mais pas à l'exécution (runtime). C'est un peu absurbe :-s.
Pour un langage compilé, ça a du sens. Java le fait et c'est bien ! Mais pour PHP, qui est interprété, c'est une perte de temps. À moins que — comme le précise Metagoto — on a une construction tardive (lazy). Dans ce cas, les annotations seraient sautées (skipped) durant l'interprétation, sauf si nécessaire. Les analyseurs lexical et syntaxique ne seraient pas énormément surchargés et donc pas forcément plus lents (car on serait sur un cas de décision typiquement LL(1), pas besoin de prédiction ou d'erreur-retour), sauf si on les utilise ! Et dans ce dernier cas, on fait soit du test, soit de la preuve et ce n'est donc pas gênant.
Ce qui reste le plus gênant en fait, c'est la syntaxe complètement débile qu'ils nous ont pondu. Ça, c'est incroyable ! Moche, ne veut rien, trop limitatif … C'est juste n'importe quoi …
Il aurait été effectivement plus intelligent de proposer une API pour manipuler des annotations dans des commentaires API plutôt que ceci … On peut toujours en parler sur @internal, desfois qu'on se fasse entendre :-).
7 De mikaelkael - 31/08/2010, 11:09
Concernant les annotations, vous oubliez un contributeur : G. Blanco qui est l'un des principaux contributeurs de Doctrine.
Dans sa version 2, Doctrine utilise énormément les annotations (http://www.doctrine-project.org/pro...).
8 De mageekguy - 31/08/2010, 11:49
@mikaelkael : Je n'oublie personne.
Guilherme Blanco a formalisé la RFC et l'implémentation technique a été faite/proposée par Pierrick.
Nul doute que ces deux personnes ont travaillé en tandem, mais chacun a fait une part distincte du travail, et comme tout le monde est de toute façon cité dans la RFC, cela importe peu.
9 De mikaelkael - 31/08/2010, 12:44
@mageekguy : j'apportais cette remarque, non pas pour souligner l'oubli, mais pour donner un exemple des annotations tel que l'a initialement imaginé Guilherme.
10 De Mathieu - 08/09/2010, 04:26
Les annotations peuvent être utilisées à bien des sauces au runtime. L'exemple du TODO est certes mal choisis mais je trouve que les annotations peuvent s’avérer très utiles. Voici quelques exemples qui me viennent à l'esprit :
- ORM
- Données destinées à du mapping
- Validation de propriétés
- Configuration de containers / frameworks
C'est sur que si c'est pour faire du @return @todo etc c'est un peu inutile mais je pense qu'il faut voir plus loin. Les annotations sont là pour ajouter des méta données sur le code, et non des commentaires donc il est important de les dissocier des phpdoc.