- Peux-tu te présenter en quelques mots ?
-
Je vais plutôt inciter tes lecteurs à aller lire mon interview précédente, car j'y répond déjà à cette question.
Oui, c’est de la fainéantise (NDLR: je n'appelle pas cela de la fainéantise mais de l'efficacité, après tout, les liens hypertextes sont fait pour cela).
- Quand as-tu découvert PHP ?
-
De mémoire, j’ai découvert le langage vers 1997.
Je me rappelle d’Altern.org et de PHP/FI.
Valentin Lacambre, l’hébergement gratuit sans publicité, ce sont mes débuts sur le web, et j’ai plongé dès le départ avec PHP.
- À tes débuts, qu'est ce qui t'as séduit dans le langage ?
-
Franchement, au début j’ai pris PHP parce que je suis tombé dessus en premier.
C’était un langage simple, accessible, et il y avait un hébergement gratuit qui le proposait.
À l’époque, il n’y avait pas d’alternative similaire.
Et puis, en ce temps là, PHP était vraiment minimal.
C’était un petit langage de script
quick‘n dirty
, voire un langage de modèles si on met de côté les fonctions d’accès aux bases de données.Bref, le langage en lui-même n’avait rien de séduisant, mais il proposait un joli premier terrain de jeu sur le web pour un ancien lycéen.
Par la suite, PHP est monté en puissance parallèlement à mes compétences et mes attentes, même s’il était à ce moment là un langage
pour mes projets personnels
.Ensuite, il y a plein de choses qui m’ont séduites, au fur et à mesure des évolutions, mais cette séduction est apparue après, lorsque j’ai eu assez d’expérience sur d’autres langages et sur d’autres domaines pour pouvoir faire une comparaison.
Mais pour moi, la magie de PHP est plus dans le fait qu’il a évolué en même temps que moi que dans les fonctionnalités qu’il a intégré au cours du temps.
Et pour en revenir à l’aspect séduction, il y a deux choses qui ont beaucoup joué dès le départ.
Il s'agit de la communauté et de la documentation.
La communauté a toujours été là, dès le début, avec le partage d’expérience, l’entre-aide, et les bouts de code.
La documentation reste une des meilleures disponibles, même si elle a plein de défauts, mais par rapport à ce que j’ai sous d’autres langages, elle est excellente, et ça aide beaucoup.
- Et au fil de ton expérience, qu'est ce qui t'as le plus rebuté ?
-
En vrac, il y a le manque de cohérence du langage et des bibliothèques de fonction, les options de configuration à gogo, le manque de vision dans l’évolution du langage, les bouts de code diffusés sur le Internet (oui, je sais, j’ai également mis ça dans les avantages) et plus tard, le fonctionnement de la core team (NDLR: aka le PHP Group).
Concernant la cohérence, certains mots clefs s’écrivent en majuscules, d’autres non.
On a parfois des exceptions, parfois des erreurs.
0 et
0
sont égaux, 0 etfalse
sont égaux, mais pas0
etfalse
.Il y a de bonnes raisons à tout cela, et d’autres raisons simplement historiques, mais on est en terrain miné et il faut faire attention à ce genre de détails pour utiliser correctement le langage.
Pour les fonctions c’est la même chose.
Une fonction peut générer des erreurs, des avertissements que je ne peux pas récupérer simplement, parfois une fonction retourne 0, d’autres fois
false
ou bien encorenull
, etc.Certes, certaines des différences sont justifiées ou compréhensibles, mais le résultat est que même avec 10 ans d’expérience, je me retrouve à regarder très fréquemment la documentation pour me rappeler l’ordre des arguments ou la gestion des cas limites.
Et devoir en permanence vérifier l’ordre des arguments et le type de retour est pénible, très pénible.
La gestion des erreurs est, elle, toujours une plaie.
Ce n’est pas pour rien que la plupart des exemples utilisent le
.mysql(i)_connect(...) or die()
Faire une gestion correcte de l’erreur est tellement complexe dans un cas réel que le reste du code devient illisible pour un simple exemple.
J’ai aussi longtemps râlé contre l’idée des
register_globals
et desmagic_quotes_gpc
.Même jeune développeur je voyais tout de suite l’erreur fondamentale que c’était.
Je peux pardonner
register_globals
de part l’historique de PHP mais pasmagic_quotes_gpc
, ni le fait que ces deux directives soient restées si longtemps actives.Bon, je critique mais c’est toi qui a demandé hein, ça ne veut pas dire que tout est négatif.
- Que reproches-tu à la core team aka le PHP Group ?
-
J’en ai déjà parlé un peu dans l'interview précédente.
Je pense que dans le cadre de cette question précise, ce qui m’a le plus manqué sont des gens passionnés prêts à faire évoluer le langage autrement que pour leurs besoins du jour.
J’ai eu plusieurs fois l’impression que les évolutions dépendaient uniquement des besoins des membres du PHP Group ou de leurs sociétés.
C’est par exemple le cas pour
DateTime
. Le besoin était criant depuis longtemps et il a finalement été comblé mais en urgence, avec un conflit vis à vis de pear, parce que (c’est mon interprétation) Derick Rethans en avait besoin pour eZ.Par contre, je ne le
reproche
pas.Il est normal et il est sain que les contributeurs visent leur besoin quand ils font évoluer PHP.
Cela permet d’éviter des délires, et puis ils n’ont aucune raison de faire autrement.
Au nom de quoi viseraient-ils mon besoin plutôt que le leur ?
Je regrette également qu’à l’époque, les désirs de la communauté n’aient pas été plus pris en compte, qu’il n’y ait pas eu plus d’échanges d’idées et de réflexions autour des idées de la core team.
Pendant longtemps, les réponses des contributeurs ont été
ce n’est pas possible
etPHP n’est pas java
, alors que des choses comme les interfaces, le typage d’argument et les espaces de nom ont finalement été implémentés.Tout comme le manque de cohérence, cela engendre également beaucoup de frustration.
Je regrette de plus qu’il n’y ait jamais eu un passionné capable d’influencer le développement de PHP pour le faire évoluer dans le bon sens, le bon sens étant bien entendu “ma vision” ;).
Là encore, je ne reproche rien puisque chacun a sa vision du langage idéal et de PHP, mais ça ne m’empêche pas de regretter que la direction prise ne soit pas celle que j’aurai choisi, et qu’au final, le résultat me rebute parfois.
Je veux cependant être clair.
Je critique, mais c’est facile de le faire de loin, après coup, et de laisser les autres travailler.
Depuis mon fauteuil, je me rends bien compte que eux
font
, et que forcément ils ne font pas tout parfaitement mais qu’au moins, ilsfont
, ce qui n’est pas mon cas (du moins pas de la même façon et pas sur le code de PHP lui même).Quand bien même j'apparais très critique je ne perds pas du tout cela de vue, et je souhaite que tes lecteurs ne le perdent pas de vue non plus : pointer tous les défauts et critiquer ce qui fonctionne mal ne doit pas être vu comme une critique des personnes et ne vient pas du tout en conflit avec l’idée globale qui est que ce qui est fait est bien.
Je sais que ma prose est souvent très critique et je tenais à rappeler qu’il ne faut pas s’arrêter à ce que j’en dis de négatif.
Et finalement, c’est aussi simplement parce que je suis frustré et que je ne m’amuse plus avec PHP que je ressens ces défauts de cohérence, d’organisation de la core team (et pas le contraire).
Le langage que j’affectionne actuellement a certainement autant de défauts, peut être même plus, mais l’amusement qu’il me procure me permet de ne pas les voir.
- Utilises-tu encore PHP actuellement ?
-
Oui et non.
Je ne développe plus en PHP, ou très rarement.
Je le faisais encore il y a un an et demi, mais peu.
C’est en grande partie due à mon évolution professionnelle, qui fait que je code beaucoup moins, tous langages confondus, et que le code que je fais est plus souvent qu’avant du code côté client que du code côté serveur, mais il n’y a pas que ça.
Du côté personnel, quand j’ai un développement à faire, j’utilise Ruby.
Ce n’est pas nouveau puisque j’en parlais déjà en 2005/2006.
Ça m’est venu un peu par vagues successives depuis.
À certains moments, je fais du Ruby, et à d’autres, je reviens vers PHP.
Mais depuis quelque temps, j’ai trop de mal à me contraindre à faire du PHP et d’ailleurs, rien que l’utilisation du mot
contraindre
est symptomatique.Du côté professionnel, par contre, PHP reste un domaine fort.
Audit, expertises, architecture, conseil, suivi technologique, une bonne partie de tout cela se fait en PHP et cela ne me pose aucun problème.
Je n’ai aucun mal non plus à souvent conseiller PHP.
Ce n’est pas tant que PHP soit mauvais ou que j’ai absolument envie d’en partir, c’est juste qu’il me frustre et que le fun n’est plus là.
- Pourquoi être passé à Ruby ?
-
L’envie d’explorer a été ma première motivation.
J’ai touché à beaucoup de choses, pas qu’à PHP et Ruby.
Il y a encore deux ans, je faisais un peu de Perl au niveau professionnel.
Actuellement, je touche encore pas mal de Javascript, j’ai donné par le passé des formations Java, et j’ai tenté sans succès d’apprendre OCaml, par exemple.
J’aurai trop de mal à vivre étriqué, sans aller voir ce qu’il y a autour, sans apprendre régulièrement quelque chose de nouveau, et sans prendre le meilleur de chaque expérience pour enrichir ma vision.
Et le problème que j’ai vis à vis de PHP vient de là.
Plus je regarde les autres langages, plus je me sent à l’étroit dans PHP.
Je ne parle pas de savoir si c’est ou non un
langage professionnel
, on a répondu plus d’une fois à cela et je n’ai pas accroché du tout à la vision de Java et à ses architectes.Je parle de passion et d’amusement, de liberté et de feeling.
Ruby m’a donné les blocs, les espaces de noms, les fonctions anonymes simples, un vrai modèle objet, la méta programmation, des attributs virtuels, une gestion d’erreur plus cohérente, un framework web plus amusant, des expressions rationnelles avec moins de six \ consécutifs, et j’en passe.
Certaines améliorations sont venues par la suite en PHP (espaces de nom, fonctions anonymes) mais ce n’est pas encore ça.
Notes que j’aurai pu passer à Python ou à autre chose, Ruby n’a été qu’une expérience.
À une époque, j’ai même hésité pendant de longs mois entre Ruby et Python.
Ce qui a été déterminant dans mon choix a été le système de blocs de Ruby, et le fait que les méthodes avec deux
_
de Python me gênaient un peu.Plus tard, l’arrivée de ROR m’a conforté dans mon choix, même si j’ai toujours envie d’explorer plus en avant Python.
Bref, je me dis que j’ai probablement plus quitté PHP que rejoint Ruby.
Ce dernier n’aurait pas été là, j’aurai pris Python, ou encore autre chose.
- Et que faudrait-il pour que tu fasses la démarche inverse ?
-
Pourquoi le ferai-je ?
Et pourquoi souhaiterais-tu que je le fasse ?
J’ai plusieurs outils, je les utilise suivant les besoins et suivant les envies.
Quand c’est côté professionnel, je fais plus attention aux besoins (d’où le fait que je travaille toujours autour de PHP) et quand c’est du côté personnel, je fais plus attention à l’envie.
En ce moment, l’envie est sur Ruby/Python, voilà tout.
J’ai plein de raisons objectives de faire moins de PHP, mais personnellement, ce qui l’emporte est toujours l’envie du moment.
Utiliser plusieurs langages est plutôt une force, et je n’ai aucune intention de faire
uniquement du PHP
, quand bien même PHP serait objectivement et de loin le langage le plus intéressant.Maintenant, si le but de la question est de savoir comment lever ce qui me gêne dans PHP, ou ce qui pourrait me faire à nouveau m’amuser avec PHP, je dirais :
- la disparition de tous les boulets historiques de php (
magic_quotes_gpc
est dans les premiers), - l’ajout d’Unicode,
- un peu de méta-programmation (et pas les annotations qu’on nous prépare, qui sont la méta-programmation du pauvre),
- des attributs virtuels (j’y tiens beaucoup),
- un framework web un peu plus simple et magique (j’ai encore du mal à voir symfony et Zend Framework comme des outils qui simplifient le travail au niveau personnel, ils ne font que cadrer et homogénéiser mais l’architecture reste assez complexe),
- plus d’homogénéité dans les fonctions (type de retour, retour en cas d’erreur),
- la refonte des erreurs/exceptions,
- quelques API objets autour des API fonctions actuelles.
Et comme je suis en train de faire un liste pour le père Noël, je m’arrête là.
Je sais que certaines choses mettront beaucoup de temps et que d’autres sont difficiles voire impossibles avec le moteur actuel de PHP et son environnement.
Et puis, pourquoi vouloir refaire ce que je connais ailleurs ?
Finalement, c’est peut être juste qui manque à PHP, ce petit quelque chose que les autres n’ont pas et qui pourrait m’amuser (un temps, jusqu’à ce que j’ai envie de faire autrement).
Actuellement je n’ai pas (ou plus) ce petit quelque chose.
- la disparition de tous les boulets historiques de php (
- Penses-tu que casser la compatibilité avec l’existant serait intéressant pour l’avenir ?
-
C’est absolument nécessaire, et plus on tarde plus c’est difficile (comprendre : si c’est si difficile c’est aussi qu’on a trop tardé).
On ne peut pas évoluer sans rien casser avec un langage qui est si contraint au départ.
Ça s’est vu avec le choix du séparateur pour les espaces de noms.
Avoir dû prendre
\
, alors qu’il a une signification spéciale très ancrée chez tous les développeurs, prouve qu’on est aux limites des ajouts possibles.Et puis, certaines choses comme la refonte des fonctions et des erreurs pour plus d’homogénéité demande forcément de casser en profondeur et d’avoir une version réellement incompatible.
Le problème est qu’il va falloir trouver le truc qu’il faut ajouter à PHP pour le rendre suffisamment attirant et ainsi justifier cette cassure de la compatibilité.
- Au final, tu n’es donc pas un vrai
switcheur
, puisque tu utilises encore PHP professionnellement. Pourrais-tu couper le cordon définitivement ? -
Damned, je suis découvert !
Non, effectivement, je n’ai pas basculé complètement comme certains.
Ceci dit je n’ai pas vocation à basculer complètement sur quoi que ce soit.
Je considère comme une très bonne chose d’avoir plusieurs cordes à son arc, et de les garder.
Un développeur se doit d’être familier avec plusieurs langages et plusieurs technologies.
Se faire enfermer dans Python ou Ruby plutôt que PHP est peut être mieux à court terme mais n’est pas mon objectif.
Pourrais-je couper définitivement le cordon ?
Probablement pas.
Il y a le côté professionnel, où forcément il est plus simple de valoriser une expertise déjà existante.
Mais il y a aussi la volonté de ne pas être mono-culture et de regarder à chaque fois ce qui est le plus approprié, sans religion établie d’avance.
Je fais aussi du Javascript avancé, j’ai fait du Perl, du Java, etc.
Il faudrait que PHP soit sacrément mauvais pour que je le mette sur ma liste noire et que je me refuse à y toucher.
Ce n’est pas le cas.
Après, il faut voir la différence entre professionnel et personnel.
Côté professionnel, je ne développe plus, ou en tout cas ce n’est pas mon rôle et ma valeur ajoutée.
Et quand il s’agit de parler expertise, architecture, besoins fonctionnels, qualité, usages ... si PHP répond aux besoins du client, je parle de PHP.
Mon travail est de résoudre les problèmes et de gérer les besoins concrets d’entreprises réelles.
Je ne souhaite pas faire n’importe quoi (et je ne le ferai pas) mais je n’ai aucun problème à travailler avec PHP quand cela est pertinent alors que pour mes développements personnels, mes besoins de passion et d’amusement me poussent ailleurs.
Chaque domaine a ses propres contraintes et ses propres critères.
Par contre je me permet de respectueusement disconvenir de ta conclusion.
Je me considère quand même comme un
switcheur
, bien que je travaille encore autour de PHP (mais pas que).Mes développements, quand j’ai le choix, se font souvent avec autre chose, et c’est dans la tête que le
switch
est surtout important.Je me sens bien plus proche de ceux qui ont basculé vers Python ou Ruby que de ceux qui sont restés avec PHP.
Je comprends et respecte les deux, voilà tout.
Je serai étonné d’ailleurs que les autres
switcheurs
ne sortent jamais PHP, par exemple pour modifier une application existante, pour faire un petit script qu’on a déjà fait avec ce langage, ou pour utiliser une bibliothèque agréable en PHP qui l’est moins sur Python (par exemple).Ce sont ces développeurs, qui ont suffisamment de recul pour ne pas être mono-maniaques, que j’apprécie le plus.
switch (true) case 'Éric Daspet': $mageekblog->interview(); break;
mercredi 13 octobre 2010. Lien permanent PHP X
Je redonne à nouveau la parole à Éric Daspet dans le cadre de cette série ayant pour thème les switcheurs
, c'est à dire ceux qui sont passés de PHP à autre chose, que ce soit Java, .NET, Python, Ruby ou tout autre langage de programmation.
Il avait en effet sous-entendu dans sa précédente interview, qui nous présentait sa vision de l'avenir pour PHP, que ce dernier n'était plus son langage de prédilection.
Il m'a donc semblé parfaitement logique de profiter de cette ouverture, purement fortuite à l'époque, pour creuser le sujet, et savoir ce qu'il en était exactement.
Et vous allez voir, ou plutôt lire, que cela en valait la peine.
Fil des commentaires de ce billet
Ajouter un rétrolien
URL de rétrolien : http://blog.mageekbox.net/?trackback/200
6 réactions
1 De gdelamarre - 14/10/2010, 11:45
non pas que je veuille te mettre en doute Eric, mais apres verification, il semble que "0" et false sont bel et bien equivalents contrairement a ce que tu indiques.
peux-tu preciser stp, j'adore ce genre de fails dans php
2 De Bruno Michel - 14/10/2010, 20:53
@gdelamarre : bien vu, "0" et false sont bien égaux.
Je pense qu'Éric pensait à NULL au lieu de false : 0 et "0" sont égaux, 0 et NULL sont égaux, mais "0" et NULL sont différents. C'est l'exemple classique pour montrer que == n'est pas transitif en PHP.
Source : http://php.net/manual/fr/types.comp...
3 De Eric D. - 15/10/2010, 08:55
Merci pour la remarque.
Il semble qu'effectivement je me sois emmêlé les pinceaux et que "0" renvoie bien false. Ce qui ne retire rien à l'argumentation d'ailleurs vu que d'autres cas existent aussi tordus à cause du transtypage inhabituel de PHP et ... le fait que je me plante encore sur des choses basiques comme ça montre bien que j'en suis réduit depuis longtemps à considérer ces possibilités comme un risque et non comme une aide (et du coup on évite à tout prix que PHP en soit réduit à ça)
4 De gdelamarre - 15/10/2010, 22:19
Eric, je ne cherchais pas à démontrer que tu avais dit une bêtise Simplement, à la fois je comprends ton argumentation, mais en même temps je ne suis pas tout à fait d'accord...
En effet, je ne trouve pas les choses si confuses. La règle est relativement simple pour "false" : lui sont équivalent (==) les valeurs false, 0, null, array() et '0'. Pour null, c'est la même chose, à part effectivement pour '0'.
On peut contester les règles, aucun problème là-dessus. Mais je ne les trouve pas si absurde que ça... "false", c'est non-vrai. On peut effectivement considérer que 0 n'est pas une valeur assimilable à vrai (on est habitués à ce qu'en binaire false soit traduit par 0 et true par 1). En revanche, null c'est l'absence d'allocation mémoire. Le néant quoi :). Vu sous cet angle, c'est nul == 0 que l'on pourrait contester, car 0 est malgré tout une valeur, qu'il faut stocker. Mais il est probable que le moteur de PHP n'alloue pas de mémoire pour stocker une telle valeur (à vérifier toutefois).
Et à dire vrai, je n'ai en tête qu'un exemple, très classique, dans lequel les équivalences trop nombreuses de false sont trompeuses : strpos. Si la sous-chaîne cherchée est au début de celle dans laquelle on cherche, il retourne l'offset 0, et donc un test du type if(!strpos(...)) renverra un faux négatif dans une telle situation. Il y a probablement d'autres exemples, mais franchement je n'en ai aucun en tête.
Cela dit, pour ne pas avoir l'air de défendre PHP à tout crin, je vais te faire une confidence : je suis personnellement excéder par ce qui suit, responsable à mon sens de nettement plus d'effets de bord :
<?php
echo sizeof(null); // renvoit 0
echo sizeof('toto'); // renvoit 1
echo sizeof(false); // renvoit 1
?>
Là, je suis complètement d'accord pour pointer une incohérence. "sizeof" attend un tableau. Dans le cas de null, sans déclencher d'erreur cependant, il nous renvoit gentiment 0, ce qui dans l'absolu n'est pas faux... Dans le cas d'une valeur scalaire quelconque, y compris "false", il transtype la valeur en tableau (array(0 => false) par exemple), d'ou le résultat de 1, qui sans être tout à fait incohérent (le transtypage nous donne une explication à ce résultat) n'en est pas moins crétin
Ajoutons à cela que foreach(null) ou foreach('toto') comme foreach(false) ou là-encore n'(importe quel scalaire produira un warning, car foreach() attend un tableau. Comme sizeof... qui lui transtype alors que foreach() grogne...
Bref, je suis personnellement beaucoup plus gêné personnellement par ceci. Mais avec de simples bonnes habitudes (utiliser is_false(), is_null(), is_array() avant un foreach(), etc.) on passe à côté de la grande majorité de ces désagrément.
Alors que tu en aies marre de PHP, soit, j'irais jusqu'à chuchoter que je te comprends, mais chut, ça doit rester entre nous. Mais pour ce genre de raison, dont à mon avis nous retrouverions des équivalents dans bien des langages, même Ruby ou Python
5 De Eric D. - 16/10/2010, 10:35
Bof bof, en gros un if($texte) valide, sauf si le texte contient "false", commence par 0 et n'est pas suivi par d'autres chiffres non nuls, donc c'est suivant le contenu (déjà c'est un comportement à débattre).
Mais en même temps ça valide la condition et retourne donc "vrai" mais c'est aussi égal à 0, qui lui retourne false. On dit que 0 == "toto" mais ils ont des comportements différents.
C'est effectivement logique en fonction du transtypage, je ne dis pas que cest crétin dans le sens "mais comment ça se fait ?" mais ça ajoute une charge cognitive non négligeable et j'ai plus d'une fois vu des codes buggués à cause de vérifications un peu rapides en true/false. On peut me dire qu'ils auraient du utiliser count(), empty(), is_null(), et plein d'autres trucs, mais je charge quand même ça un peu aussi sur la responsabilité du langage qui les laisse croire que ça réagirait "simplement" sans en avoir besoin.
A coté de ça certaines fonctions sont préfixées par leur module, d'autres non (et parfois pour un même module), certains préfixes sont séparés par _, d'autres non (et parfois pour un même module), certaines retournent par valeur et d'autres par référence (dans les fonctions de tableaux c'est un gros piège à débutant), parfois les paramètres sont dans un ordre contestable, voire incohérent avec d'autres fonctions similaires du même module.
Tout ça peut être compréhensible, historique, mais quand tu regardes du côté de ruby (puisque tu en parles), tu te poses bien moins la question de ce qui est false ou null, les règles sont fermes, l'ordre des arguments ou le mode de retour. Ca permet de coder avec une charge cognitive plus petite, de ne pas avoir besoin de "savoir" mais de trouver ça logique.
Ruby a d'ailleurs un ajout que j'aime beaucoup : quand tu as une méthode dangereuse ou qui modifie directement l'objet (genre tu trie le tableau de base au lieu d'obtenir une copie triée) tu as un ! accolée à la méthode. Le bénéfice de simplicité et de "je pense à ce que je fais et non comment je le fais" est énorme, meme si ça n'a l'air de rien.
PHP non seulement n'a pas ça, mais en plus j'ai besoin de me souvenir de la fonction ou (souvent) de vérifier dans la doc, parce que je ne peux pas me baser sur des convention respectées et cohérentes.
On s'y fait, mais c'est juste agaçant, frustrant, et un soulagement quand on code sur autre chose.
6 De metagoto - 16/10/2010, 16:26
@gdelamarre
Personnellement, je n'ai rien contre le comportement de sizeof(). C'est un alias pour count(). On peut voir count comme retournant la dimension de la variable. Pour un array c'est sa longueur (array de dim 1 --> variable de dim N), pour tout le reste c'est 1 ou 0 pour null (ok, il y a aussi l'interface Countable).
Je ne dirai pas que null est une absence d'alloc mémoire. C'est juste autre chose que true, false, int, float etc. null a la même taille que les autres types POD (les types primaires true, false, long, double). Et cette taille n'est pas si "négligeable" que ça. Une bonne vingtaine de bytes.
Au moindre doute, on peut utiliser l'opérateur ===. Les règles un peu spéciales de conversions et de tests rendent quand même beaucoup de services. C'est en les supprimant qu'on verrait à quel point elles sont utiles et définissent la "patte" de php. D'ailleurs les sérieux griefs à propos d'un hypothétique "strict type hinting" dans php concernent ce point.