Et bien au risque de décevoir, il n'y a ni vaincu ni vainqueur.
En effet, les contributeurs ont énormément discuté, à tel point que La liste de diffusion internals@ est littéralement saturée de message sur le sujet.
Personnellement, j'ai arrêté de lire dans le détail chaque message à partir du centième, mais cela ne m'empêche pas de pouvoir dire que chacun a eu l'occasion de faire valoir son point de vue, qu'il soit contributeur ou simple utilisateur du langage.
Il ressort de ce dialogue trois propositions, présentées dans la RFC exposant le point de vue de Zeev Zuraski.
Ces propositions visent à modifier le contrôle de type tel qu'il a été conçu par Ilia :
- Si l'argument reçu n'est pas du type attendu, il sera converti suivant les régles de conversion actuelles de PHP et une erreur de type E_STRICT sera générée par le langage en cas de perte de précision induite par la conversion.
- Si l'argument reçu n'est pas du type attendu, il sera converti suivant des régles de conversion plus strictes que celles utilisées actuellement par le langage et une erreur de type E_STRICT sera envoyée par le langage en cas de perte de précision induite par la conversion.
- Si l'argument reçu n'est pas du type attendu, il sera converti suivant les régles de conversion actuelles de PHP et une erreur de type E_FATAL sera générée par le langage en cas de perte de précision induite par la conversion.
En résumé, si l'une de ces trois propositions est acceptée, il n'est plus question d'une vérification du type des arguments mais bien d'une conversion du type des arguments vers le type requis, s'il y a lieu.
Par ailleurs, cette conversion sera automatique et transparente pour l'utilisateur dans une grande majorité des cas.
J'avoue que dans un premier temps, mes poils d'ancien développeur C++ se sont hérissés très fort à la lecture de ces propositions.
Mais à mieux y réfléchir, chacune de ces solutions permettent d'obtenir le même résultat que la modification originelle d'Ilia.
En effet, quelque soit la solution retenue, le concepteur d'une fonction ou d'une méthode sera certain de manipuler des arguments correspondant au type qu'il désire.
Cependant, du point de vue de l'utilisateur de la méthode ou de la fonction, les choses seront beaucoup plus simples car il n'aura pas à se soucier du types des arguments qu'il passera à la méthode ou à la fonction, du moins dans une grande majorité des cas.
Car si par hasard l'utilisateur pousse le bouchon un peu loin en passant un argument qui nécessite une conversion trop violente
, il en sera informé par la langage via un message d'erreur.
Je pense donc que ces propositions représentent un compromis acceptable, même si la modification d'Ilia me convenait parfaitement et que j'aurais apprécié un changement plus radical plutôt qu'une solution qui ménage la chèvre et le chou.
Cependant, beaucoup de temps et d'énergie ont été perdu consacré à ce sujet et je pense donc qu'il est maintenant plus que temps d'avancer sur d'autres sujets, d'autant que pour l'instant, aucune décision définitive n'a été prise sur celui-ci.
4 réactions
1 De Olivier Mansour - 31/05/2010, 19:05
Je suis aussi un peu déçu de ce recul. On aurait gagné pas mal de temps et éviter les is_* etc... vérifiant les types de données. L'avantage des solutions présentées est qu'elles vont permettre tout de même d'imposer à une équipe projet le respect des types de variables déclarées (en chassant, au pire, les erreurs E_STRICT), et ça c'est quand même bien.
2 De mageekguy - 31/05/2010, 19:46
@Olivier Mansour : Quelque soit la solution retenue, l'utilisation des fonctions du type
is_*ne sera plus nécéssaire, PHP se chargeant de faire la conversion nécéssaire pour que le type voulu soit celui reçu.De plus, rien n'est encore joué, vu qu'une nouvelle RFC reposant sur l'autoboxing vient d'être proposée pour résoudre le problème.
3 De metagoto - 31/05/2010, 22:33
Davey Shafik a proposé un truc vraiment sympa dans la mailing list qui permettrait de supporter à la fois le strict et le weak type hinting:
func(int $i)
func((int) $i)
Le 1er est strict, le 2nd est weak.
Dommage, ça ne se fera pas. Toute notion de "strictness" sera écartée par Zeev, Stas et d'autres cadors.
L'essentiel c'est qu'une fois dans le corps des fonctions, les variables aient le bon types. Le weak type hinting est donc non seulement plus proche du comportement de php que l'on connait, mais aussi et surtout beaucoup plus user-friendly.
Néanmoins, pour de simples questions de perf, pouvoir supporter aussi, et sur demande, du strict type hinting ne m'aurait pas dérangé.
Moi ce qui m'a le plus déplu dans la longue thread de la mailing list, c'est à quel points les simples utilisateurs de php sont considérés comme des incapables. "ils ne savent pas c'est quoi un type", "ils ne savent pas caster", "ils ne vont pas comprendre..". Alors qu'on parle d'un truc purement optionnel qui de toute façon sera avant tout réservé aux calls inter-composants/libraries.
4 De mageekguy - 01/06/2010, 09:30
@metagoto : J'essaye de faire abstraction de l'arrogance de certains sur internals@, sinon, je me sauve en courant ;).