Ce mois-ci sur internals@php - Janvier 2014

le - Lien permanent 6 commentaires

This post is also available in english.

L’année 2014 a commencé par un mois de janvier bien rempli, avec 963 messages, soit le double du mois précédent !

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


Le 15 janvier, Ferenc Kovacs a annoncé qu’il allait tagger PHP 5.6-alpha1 — cette version a été publiée quelques jours après, le 24 janvier.

La sortie de cette première version alpha signifie que (en théorie) plus aucune nouvelle RFC ne peut être proposée pour PHP 5.6. Julien Pauli a répondu en souligant qu’aucune RFC ne sera mergée (inclue à PHP 5.6) une fois la phase de versions beta commencée — la première version beta pouvant arriver aux environs de mi-mars.

Adam Harvey a quant à lui commencé à travailler sur la page de documentation Migrating from PHP 5.5.x to PHP 5.6.x.


Certaines fonctionnalités ont été marquées comme obsolètes lors de la sortie de PHP 5.5 : le modificateur /e pour preg_replace(), l’extension ext/mysql, … En suivant le cycle de releases, ces fonctionnalités obsolètes devraient être supprimées de PHP 5.6 (et/ou déplacées vers PECL lorsqu’il s’agit d’extensions comme ext/mysql).

Comme l’a rapidement fait remarquer Andrea Faulds, on trouve encore beaucoup de code utilisant les fonctions mysql_*(), et déplacer l’extension correspondante vers PECL risque de poser quelques problèmes — ceci dit, libre aux distributions de continuer à fournir cette extension. De plus, ce n’est pas parce que nombre de tutoriaux (et quelques logiciels répandus) continuent d’utiliser des fonctions déconseillées depuis des années qu’il faut arrêter de faire évoluer PHP.


Alors que plusieurs idées en cours de discussion apporteraient des modifications plus impactantes que celles vues sur PHP 5.3/4/5, Adam Harvey a demandé s’il ne serait pas temps de commencer à réfléchir à une prochaine version majeure de PHP — c’est une idée qui a déjà été évoquée quelque fois ces derniers mois, d’ailleurs.

Comme l’a fait remarquer Julien Pauli, au-delà des modifications cassant la compatibilité antérieure, une nouvelle version majeure serait aussi l’occasion de faire une passe de ménage — après tout, PHP 5.0 avait bien introduit une nouvelle version du Zend Engine. Ferenc Kovacs a alors noté, comme il l’avait déjà dit il y a quelques mois, qu’aucun processus n’a été jusqu’à présent défini quant à la sortie d’une nouvelle version majeure.

Pour faciliter le passage à cette prochaine version et éviter qu’il ne s’étale sur plus de 5 ans comme ce fût le cas pour PHP 5, une piste serait de profiter de l’existence du FIG pour synchroniser une montée de version au niveau des frameworks les plus utilisés.

Rasmus Lerdorf a rappelé que, selon lui, PHP devrait rester un langage pragmatique, tourné vers le web (les besoins correspondant ont évolué), faiblement typé, et qui prend en compte les besoins et capacités d’un large registre de développeurs. Le support d’Unicode serait indispensable, les performances ne sont pas à oublier, et PDO gagnerait à ce qu’on s’en occupe un peu plus. Tout ceci est moins sexy que de nouvelles fonctionnalités, mais il ne faut pas oublier que ces points répondent aussi à des besoins réels. Julien Pauli a répondu avec quelques idées qu’il avait, comme une VM threadée ou des améliorations et optimisations au niveau de celle-ci.

Andrea Faulds a continué avec un sujet à propos de la sensibilité à la casse en PHP : est-ce qu’une prochaine version majeure ne serait pas l’occasion d’uniformiser un peu, à ce niveau ?

En parallèle, Rasmus Lerdorf a répondu sur un fil de discussion à propos de ce que certains appellent inconsistance dans les noms de fonctions de PHP et les paramètres qu’elles attendent (et l’ordre de ceux-ci) : depuis toujours, PHP a été une sur-couche à des dizaines (des centaines, maintenant) de bibliothèques. Ces fonctions ne sont pas spécifiques à PHP : elles sont inscrites dans la mémoire d’un nombre de développeurs, pas parce que nous écrivons du PHP, mais parce que nous vivons toujours dans un monde écrit en C — et dès que nous nous aventurons hors de PHP et des langages de script, nous rejoignons celui-ci. Ceci dit, comme l’a répondu Larry Garfield, aujourd’hui, seul un petit nombre de développeurs PHP ont connaissance de C ou de POSIX… En fait, C ne doit être la seconde langue que d’un nombre très réduit de développeurs PHP. Suite à ces échanges, un tout début de RFC a été mis en place : RFC: Use alias to provide both legacy and consistent names.

De son côté, Pierre Joye a lancé un troisième sujet de conversation à propos de PHP 6, où il a noté qu’il est important de réfléchir aux impacts que diverses modifications pourraient avoir en termes d’adoption d’une future version du langage (l’idée évoquée plusieurs fois étant d’éviter de se trouver dans une situation équivalente à celle de Python 2 et Python 3).


Alors que HHVM fait de plus en plus souvent parler de lui, zhifeng hu a demandé s’il serait possible de l’introduire dans le code de PHP.

Pierre Joye n’a pas tardé à répondre que, bien qu’intéressante sur de nombreux points, cette idée ne lui semblait pas envisageable pour l’instant, notamment parce que HHVM est contrôlé par une unique entreprise, parce que signer un CLA est nécessaire pour y participer, ou parce qu’il est peu portable (requiert le compilateur GCC). De plus, comme remarqué par Andrea Faulds, HHVM ne correspond pas à une implémentation complète des fonctionnalités de PHP — surtout, comme l’a noté Sara Golemon, pour ce qui est des extensions intégrées ou fournies via PECL.

En somme, cette proposition serait peut-être en avance d’un an ou deux, en l’état actuel de PHP et de HHVM.


Sara Golemon a rédigé la RFC: __debugInfo(), qui vise à exposer à l’espace utilisateur des informations de debuggage déjà connues en interne — en ajoutant une nouvelle méthode magique __debugInfo(). Cette proposition permettrait de personnaliser les sorties de debug.

Parmi les retours, certains ont noté qu’un nom comme __dump() pourrait être plus parlant pour les développeurs PHP ne connaissant pas le fonctionnement interne du moteur, d’autres ont noté que cette fonctionnalité devrait aussi être intégrée à l’API de Reflection. Il a aussi été noté qu’avec une telle fonctionnalité, var_dump() pourrait ne plus toujours afficher la vérité.


Kevin Ingwersen a relancé un sujet à propos de la RFC: Named Parameters, rédigée en septembre 2013, mais qui n’avait plus fait l’objet de discussion depuis quelques temps.

Nombreux sont ceux qui aimeraient voir ce type de fonctionnalité arriver dans PHP — même si d’autres ont fait remarquer que cela demanderait d’écrire plus de code pour les appels de fonctions. En fait, les paramètres nommés aideraient surtout pour les appels de fonctions acceptant un nombre conséquent de paramètres.

Nikita Popov, auteur de la RFC en question, a dressé un rapide résumé de la situation : dans l’ensemble, les principales questions en suspend ont toutes une réponse, et l’implémentation de la fonctionnalité est prête. Par contre, il est nécessaire de passer sur l’ensemble des fonctions exposées par PHP pour s’assurer que leurs définitions de paramètres soient acceptables (qu’ils aient des noms cohérents, en particulier), et de vérifier que la lecture de paramètres fonctionne, partout, pour ces mêmes fonctions internes. Ces deux points demandent énormément de travail et il est peu probable que ce soit terminé d’ici le feature freeze de PHP 5.6.


Philip Sturgeon a rédigé la RFC: Array Of, dont l’idée est d’améliorer le type-hinting de PHP de manière à pouvoir indiquer qu’un tableau d’éléments d’un type donné est attendu. Par exemple :

function test(SplFileObject[] $files) {
  var_dump($files);
}

Les premiers retours ont semblé indiquer que l’idée en intéressait plus d’un — et le sujet, avec pas loin de 100 mails sur environ une semaine, a été un des plus discutés ce mois-ci sur internals@ ! Notons que cela n’a pas empêché quelques retours assez durs ou soulignant que ce type de fonctionnalité (contrairement à d’autres RFC passées ces derniers mois) peut déjà être implémentée en PHP ou ne colle pas forcément à une partie de la philosophie souple du langage. Une réponse à quelques uns de ces retours a été apportée ici.

Une question qui s’est rapidement posée est de savoir s’il était possible d’indiquer si des éléments du tableau pouvaient être NULL (ce qui pourrait mener à des erreurs lors de parcours), et avec quel type de syntaxe. Bien sûr, l’impact sur les performances est aussi à prendre en compte — mais le serait aussi si les vérifications de types étaient réalisées en espace utilisateur.

En fait, comme l’a souligné Julien Pauli un peu plus loin dans la discussion, cette RFC illustre le fait qu’il manque à PHP une notion de “tableau typé” — qui irait plus loin que la vérification de types lors du passage de paramètres. Au passage, même si cette RFC n’a rien à voir avec ces deux points, quelques uns ont reparlé de type-hinting sur types scalaires et de Generics.

En parallèle, Sara Golemon a posté un récapitulatif de ce que permet et accepte HHVM pour les tableaux typés et les Generics — à la fois en visant à arriver à une syntaxe commune et pour résumer les cas tordus identifiés de leur côté.

Suite à cela, Philip Sturgeon a demandé s’il y avait un intérêt pour les Generics — ce qui pourrait avoir une influence sur la syntaxe de Array Of.

Au passage, notons que ce fil de discussion a encore une fois illustré le fait que le type-hinting et ses éventuelles extensions est toujours un sujet chaud !


Yasuo Ohgaki a rédigé la RFC: Multibyte Char Handling, où il propose d’ajouter de nouvelles fonctions pour gérer des chaînes de caractères en encodages sur plusieurs octets.

Plusieurs approches seraient possible, en fait : ajouter de nouvelles fonctions, se baser sur la locale courante (ce qui semble être une mauvaise solution), ou même ajouter un paramètre supplémentaire encodage comme cela a par exemple été fait pour htmlspecialchars().

Comme l’a souligné Derick Rethans, au lieu d’ajouter encore et encore de nouvelles fonctions (que les développeurs PHP doivent ensuite choisir d’utiliser lorsque c’est nécessaire), une meilleure approche serait sans doute un réel support d’Unicode par PHP — comme visait à le faire PHP 6 il y a quelques années !

Et suite à cette discussion, la RFC: Alternative implementation of mbstring using ICU a aussi été mise à jour.


Anatol Belski a annoncé que les choses avaient suffisamment avancées sur la RFC: 64 bit platform improvements for string length and integer in zval pour que les discussions puissent commencer (il y a eu environ 200 mails échangés sur le sujet ce mois-ci, tout de même !).

Pour essayer de résumer les échanges en quelques mots : l’objectif ici est d’améliorer le support des plate-formes 64 bits par PHP (notamment sous Windows), sans que cela n’ait d’impact sur les plate-formes 32 bits.

Une conséquence non-négligeable est qu’il faudrait repasser sur toutes les extensions existantes pour modifier quelques appels de fonctions (comme zend_parse_parameters() et *printf()) et quelques utilisations de macros. Ceci demanderait quelques heures à quelques jours de travail pour chaque extension. Mais cela représente un risque réel, puisque toutes les extensions, y compris celles développées par des entreprises pour leur besoins internes1 et non rendues publiques, devront être modifiées — et que toutes ne le seront certainement pas au moment de la sortie de PHP 5.6. De ce fait, il pourrait s’agir d’une modification trop importante pour PHP 5.6.

Les votes ont été ouverts en fin de mois ; les résultats seront donc pour le mois prochain. Quelques premières explications sur des votes négatifs ont d’ailleurs insisté sur le trop grand impact de cette modification pour PHP 5.6, et le fait qu’elle trouverait mieux sa place vers une future version majeure.

En parallèle de cette discussion sur les améliorations 64 bits, Anatol Belski a créé la RFC: Removal of dead SAPIs. Comme l’a noté Julien Pauli, ces vieilles SAPI qui datent pour certaines des années 90 et ne sont plus utilisées/maintenues pourraient être supprimées.


Tout juste le premier jour du mois, Daniel Lowrey a annoncé la fin des votes sur la RFC: TLS Peer Verification. Avec 25 votes “pour” et aucun vote “contre”, voici une amélioration de sécurité qui arrivera avec PHP 5.6. Quelques jours après, il a continué sur le sujet, avec la RFC: Improved TLS Defaults qui vient en complément de la précédente.

Dans la foulée, Ondřej Hošek a ouvert les votes sur la RFC: ldap_modify_batch, qui visait à ajouter une nouvelle fonction à l’extension ldap. Avec 5 votes “pour” et 0 vote “contre”, elle est passée et la nouvelle fonction pourrait donc faire partie de PHP 5.4 et versions supérieures.

Sara Golemon a rédigé la RFC: GMP Floating Point Support en extrayant une portion de la RFC: GMP number as PHP number qui a quant à elle été retirée.

La RFC: Argument Unpacking avait été ouverte aux votes à la fin du mois dernier. Avec 32 votes “pour” et 2 votes “contre”, elle est passée. Cette nouveauté, qui arrivera pour PHP 5.6, complémente la RFC: Syntax for variadic functions qui était passée il y a quelques mois.

Daniel Lowrey a commencé à travailler sur une série de modifications visant à permettre un fonctionnement non-bloquant pour ext/pgsql. En parallèle, Yasuo Ohgaki a implémenté le support d’objets de plus de 2 Go (arrivé avec PostgreSQL 9.3).

Yasuo Ohgaki a annoncé la fin des votes sur la RFC: Use default_charset As Default Character Encoding : avec 8 votes “pour” et 1 vote “contre”, elle est passée. Dans la foulée, il a indiqué avoir travaillé sur la RFC: Multibyte Char Handling et souhaiter des commentaires sur le sujet.

Dmitry Stogov a annoncé avoir commencé à travailler sur un possible nouveau gestionnaire de mémoire pour PHP. En l’état, ce prototype ne fonctionne que sous Linux (sur un build de PHP sans information de debug), et semblerait apporter dans les 3% de gain de performances sous Drupal et entre 12% et 15% sur une portion de code très gourmande en construction d’objets.

Sara Golemon a rédigé la RFC: Module API Inspection, qui ajouterait deux options à PHP en ligne de commande, permettant de déterminer la version de modules zend gérée par PHP, ainsi que celle contre laquelle une extension a été compilée. Toutefois, la solution mise en place n’est pas parfaite, et il n’est donc pas certain qu’elle soit validée.

Andrea Faulds a annoncé l’ouverture des votes sur la RFC: Alphanumeric Decrement. Avec 21 votes “contre” et aucun vote “pour”, elle a été rejetée à l’unanimité.

Les votes ont été ouverts sur la RFC: Introduce session options - read_only, unsafe_lock, lazy_write and lazy_destroy. Suite à cela, les discussions sur le sujet sont reparties, et les votes ont été arrêtés, le temps d’apporter quelques mises à jour la RFC.

En toute fin de mois, Gordon Oheim a annoncé l’ouverture des votes sur la RFC: Automatic Property Initialization, qui vise à faciliter l’initialisation de propriétés lors de l’écriture d’un constructeur, à l’aide d’une syntaxe de ce type :

// would assign properties and provide $z as a local variable
public function __construct($this->x, $this->y, $z)
{
    // do something with $z locally
}

À suivre le mois prochain, donc ;-)



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.



  1. Yahoo aurait de l’ordre de 500 extensions PHP en interne, selon ce mail

Vous avez apprécié cet article ? Faites le savoir !

Commentaires

1. Par Jérémy le 2014-02-10 09:41
Jérémy

Rasmus Lerdorf a rappelé que, selon lui, PHP devrait rester un langage pragmatique, tourné vers le web (les besoins correspondant ont évolué), faiblement typé, et qui prend en compte les besoins et capacités d’un large registre de développeurs.

Faiblement typé … C’est quand même drôle que de plus en plus de langage Web (ou qui s’oriente vers le web) deviennent de plus en plus typés justement pour éviter au max les effets de bords …
C’est triste que ce type “dirige” PHP et que beaucoup de dev interne le suivent dans ses propos.

Le bon point dans tout ça c’est qu’ils commencent à penser à PHP6 ! J’espère que les anciens feront pas trop ch*** et laisseront un peu le langage évoluer et être consistent. Car PHP est utilisé par des Dev’s PHP par pas des types qui font du C.
Un bon point serait donc qu’ils écoutent les Dev’s PHP !
Croisons les doigts ! :D

2. Par Yoann le 2014-02-10 12:06
Yoann

J’ai beaucoup de mal à comprendre ce débat sur le typage.

Autant je peux comprendre que l’on souhaite permettre le typage faible, mais ce que je ne comprend pas c’est pourquoi empêcher un typage un peu plus fort ? Les deux ne sont pas forcement incompatible..

La où un typage un peu plus fort serait appréciable à mon goût, c’est pour les paramètres d’entrées d’une fonction/méthode.

si on permet de faire

function doSomething($objectValue) {…} ou function doSomething(\Object $objectValue) {…}

pourquoi ne pas permettre de faire ?

function doSomething($numericValue) {…} ou function doSomething(int $numericValue) {…}

cela permettrait à ceux voulant typer un peu plus de le faire, tout en laissant ceux qui ne veulent pas de ne pas le faire et de ne pas casser la compatibilité.

Si quelqu’un connait la raison profonde de l’aversion de Rasmus Lerdorf contre le typage (peut-être a t’il été agressé par une méthode fortement typé étant petit je sais pas) ou qui souhaite simplement partager son point de vue dans ce débat ancestrale, je suis tout ouïe.

En tout cas félicitation pour cette série d’article sur le @internals que j’attends chaque mois avec impatience !

3. Par Pascal MARTIN le 2014-02-10 12:52
Pascal MARTIN

@Jérémy > je n’ai pas le sentiment que Rasmus “dirige” PHP (d’autant plus que PHP ne suit pas un modèle de développement avec un “dictateur” à sa tête — ce qui explique le développement parfois chaotique ; et qui est parfois source de reproches du style “ça serait mieux avec un dictateur”) : il donne son avis, comme d’autres.

Cet avis est souvent assez tranché et tient parfois compte de retours différents de ceux que l’on entend souvent, certes, mais il s’agit d’avis personnel tout de même.

Les anciens qui, pour certains, ont tendance à freiner la volonté d’évolutions rapides apportée par certains plus nouveaux ont un point de vue qui peut être considéré comme défendable aussi, ne l’oublions pas — même si ce n’est pas nécessairement celui que nous partageons. Un bon argument qu’il est difficile de leur refuser est qu’ils savent ce qu’implique la maintenance : depuis des années, ils se chargent de celle-ci, alors que d’autres ont ajouté plein de fonctionnalités plus sexy (et la maintenance, c’est souvent bien moins fun que le développement de nouveaux trucs).

Écouter les développeurs PHP, oui, c’est nécessaire. Mais, dans le même temps, si “corriger les inconsistances” apporte tellement de cassures de compatibilité que cela signifie que personne ne fera la bascule PHP 5.x -> PHP 6…


@Yoann > permettre un typage fort n’est pas nécessairement incompatible avec un typage souple, en effet ; au premier abord du moins.

Par contre (pour ne donner que deux arguments — et peut-être me faire un peu l’avocat du diable) :

  • A partir du moment où ce typage fort va commencer à être utilisé (dans des tutoriaux, dans le manuel, dans des bibliothèques, dans des logiciels open-source), c’est une notion supplémentaire que des débutants devront comprendre,
  • Une nouvelle fonctionnalité, potentiellement impactante en termes de code ajouté au milieu du moteur de PHP, ajoute aussi un coût de maintenance non-négligeable. Si on regarde le nombre de bugs actuellement ouverts sur le bug-tracker de PHP, on se rend compte que la maintenance (rien que le triage de bugs !) semble intéresser moins de développeurs que les débats sur les nouveautés — et plus il y aura de fonctionnalités (encore plus si elles sont nouvelles / récentes) plus il y aura de bugs. En tant que développeur moi-même, si je vois les bugs s’empiler sur mon logiciels, je vais avoir tendance à aller voir mes collègues et à leur demander pendant un moment d’arrêter de coder des nouveautés à tour de bras pour m’aider un peu à dépiler les bugs sur l’existant. Peut-être que certains développeurs de PHP aimeraient pouvoir faire pareil (ou être entendu quand ils le font)…

Du typage fort sur des objets, j’apprécie. Ne serait-ce que parce qu’un objet a un comportement, doit exposer des méthodes — et que ça plantera lamentablement si j’essaye d’appeler une de celles-ci sur quelque chose qui n’est pas un objet du bon type.

Du typage souple sur des types scalaires, par contre, ça reste un point que j’apprécie en PHP (quand c’est bien utilisé, hein). Je suis content de pouvoir écrire quelque chose de ce type :

ma_fonction($_GET['id']);

sans avoir à me demander si ma_fonction() n’attendrait pas en fait toujours un int fortement typé, et que je risque donc de me prendre une erreur si je ne transtype pas moi-même $_GET['id'] en int.

En fait / de plus, considérer qu’une chaîne qui contient la représentation textuelle d’un entier est égale à la valeur de ce même nombre entier… C’est quand même bien pratique, non ? Même si d’aucun (moi y compris, certains jours ^^) diraient que c’est moche


Des fois, je me dis qu’il faudrait vraiment que j’écrive cet article que j’ai à l’esprit depuis quelques temps, à propos du fait que PHP est destiné non pas à un seul ensemble de développeurs et à un usage unique, mais à une multitude…

Quand on dit “écouter les développeurs PHP”, est-ce qu’on ne pense pas uniquement à ceux “qui s’expriment” ? Ceux qui vont en conférences, qui vont aux Aperos PHP, qui postent sur leurs blogs ou échangent sur Twitter… Et ne représentent peut-être, finalement, qu’une infime minorité de tous ceux qui manipulent, régulièrement ou non, PHP ?

4. Par Jérémy le 2014-02-10 13:24
Jérémy

Je suis justement occupé à dev une plateforme de partage pour les Dev non internes !
Nous verrons ce que ça donne à terme :D

Je suis bien d’accord concernant la maintenance mais pour moi si une nouveauté n’implique pas de BC pourquoi ne pas l’ajouter ?
J’ai parfois l’impression qu’en interne ils cherchent des BC la ou il y en a pas forcement (bon après c’est peut-être dut à ma jeunesse qui veut voir vite tout évoluer :D)

5. Par Yoann le 2014-02-10 16:37
Yoann

A partir du moment où ce typage fort va commencer à être utilisé (dans des tutoriaux, dans le manuel, dans des bibliothèques, dans des logiciels open-source), c’est une notion supplémentaire que des débutants devront comprendre.

Je ne suis pas sûr que l’on puisse associer ça comme une nouvelle notion à comprendre, car même si on parle de typage faible, on parle tout de même de typage. Sans parler du fait que vu que cette notion existe déjà pour les objets, les débutants seront quand même amener à la connaitre.

Pour ce qui est du typage des paramètres d’entrées en tout cas, j’aurai tendance à dire que cela s’approche plus d’un sucre syntaxique, que d’une fonctionnalité à part entière. Cela n’empêche aucunement les développeurs de vérifier le type des paramètres en entrée d’une méthode. J’irai même jusqu’à dire que cela pourrait dans certains cas être plus déroutant car au lieu d’avoir une exception (ou fatal error) standard, chaque librairie aurait sa propre manière de traiter ce cas là ou son propre message d’erreur. Ce qui pourrait rendre le tout plus complexe à gérer. Ou même si ce n’est pas du tout gérer obtenir une erreur un peu plus au niveau qui n’indiquerai pas forcement que l’erreur vient d’une mauvaise valeur d’entrée.

En ce qui concerne les débutants. Pour ceux qui ont eu une formation, il est rare qu’on leurs apprennent que PHP, dans mon cercle de développeur, ils ont tous au moins fait du C, C++ ou Java. Et pour les autodidactes et même les autres d’ailleurs, cela reste tout de même une notion ultra basique.

Une nouvelle fonctionnalité, potentiellement impactante en termes de code ajouté au milieu du moteur de PHP, ajoute aussi un coût de maintenance non-négligeable. Si on regarde le nombre de bugs actuellement ouverts sur le bug-tracker de PHP, on se rend compte que la maintenance (rien que le triage de bugs !) semble intéresser moins de développeurs que les débats sur les nouveautés — et plus il y aura de fonctionnalités (encore plus si elles sont nouvelles / récentes) plus il y aura de bugs. En tant que développeur moi-même, si je vois les bugs s’empiler sur mon logiciels, je vais avoir tendance à aller voir mes collègues et à leur demander pendant un moment d’arrêter de coder des nouveautés à tour de bras pour m’aider un peu à dépiler les bugs sur l’existant. Peut-être que certains développeurs de PHP aimeraient pouvoir faire pareil (ou être entendu quand ils le font).

Sur ce point, je suis entièrement d’accord avec toi (je ne vois pas comment on pourrait être contre sincèrement). Mais (il fallait quand même un mais ;)) cela est valide pour toutes évolutions qui sera faite au cœur de PHP, on peut donc difficilement donner cette argument pour justifier le non ajout d’un typage un peu plus fort. Cela lève par contre un autre débat intéressant sur l’évolution et la stabilisation de PHP et si je me souvient bien, il y a eu quelques discussions la-dessus dans le @internals les mois d’avant.

Des fois, je me dis qu’il faudrait vraiment que j’écrive cet article que j’ai à l’esprit depuis quelques temps, à propos du fait que PHP est destiné non pas à un seul ensemble de développeurs et à un usage unique, mais à une multitude…

Justement est-ce que de forcé l’utilisation du typage faible, n’est pas contre cette esprit qui veut que PHP soit pour tout le monde ?, au même titre que de forcer l’utilisation du typage fort.

Bref, tout ça pour dire que, je n’ai rien contre le typage faible, il a ces avantages et inconvénients comme pour le typage fort. C’est juste qu’un petit pas dans cette direction pourrait à mon avis faire plaisir à pas mal d’entre nous qui aimons PHP.

Après peut être que c’est aussi à nous (devs PHP) a retrousser nos manches et a aller voir comment ça se passe sous le capot et à apporter notre contribution, ça ne peut qu’être bénéfique à tout le monde au final.

6. Par Pascal MARTIN le 2014-02-10 22:06
Pascal MARTIN

@Jérémy >

si une nouveauté n’implique pas de BC pourquoi ne pas l’ajouter ?

Une réponse possible, mais probablement pas la seule, serait : parce qu’elle introduit de la complexité (au niveau du langage, au niveau du moteur de PHP, au niveau de la maintenance future, … ).


@Yoann > j’ai moi-même commencé à coder avec une sorte de truc un peu inspiré de Basic et de Pascal (sur TI-83 puis TI-92+) qui n’étaient pas typés du tout. Quand je suis ensuite passé au C, statiquement typé, ça m’a fait un choc, mais j’ai tenu le coup. Quelques mois après, j’ai commencé à faire un peu de PHP en passant. Ce n’est qu’un à deux ans plus tard que j’ai découvert la notion d’objets en C++, et j’avais déjà mis en place quelques sites en PHP (et j’en ai développé d’autres ensuite toujours sans la moindre trace d’objet), sans que mon ignorance ne m’empêche de faire des trucs qui marchent (bon, par contre, niveau maintenabilité… je me suis vite rendu compte que ce que j’avais fait était atroce :-D Mais j’étais débutant, et c’est une bonne façon d’apprendre ^^ ).

PHP, de base, tu n’as pas réellement besoin de comprendre les concepts objets : tu peux tout à fait mettre en place des scripts utiles, qui te rendent service en automatisant une partie des tâches répétitives que tu peux avoir à effectuer, sans jamais utiliser de classe. Éventuellement, avec des versions récentes de PHP 5.x il te faudra comprendre un peu qu’il faut utiliser new et -> pour certains trucs, ce qui demande déjà un petit pas de plus que de simples appels de fonctions, mais n’impose pas de comprendre ce que sont des objets. Avec des années (je veux bien ramener à des mois) d’expérience, oui, la notion d’objet peut sembler “basique” ; mais je ne suis pas convaincu qu’elle le soit réellement ; et il n’est pas obligatoire de la maîtriser pour réussir à mettre en place des programmes utiles.

Ce que je veux dire par là, c’est que chaque notion que tu ajoutes, chaque notion qu’il est nécessaire de comprendre pour pouvoir utiliser le langage, c’est autant de barrières pour les débutants et les amateurs qui n’ont pas besoin d’être “pro” et veulent seulement mettre en place quelques scripts leur facilitant la vie.

Bien sûr, les besoins de ce public ne sont pas les mêmes que ceux que toi et moi pouvons avoir dans notre vie professionnelle ou d’amateur éclairé. Mais est-ce que PHP doit pour autant oublier ce public qui a fait sa force ? On pourrait en discuter pendant des heures, de cette question… Je doute qu’il existe une vraie réponse ^^


Pour ce qui est de la formation, la mienne date pas mal (j’ai passé le Bac en 2001, j’ai décroché mon DUT en 2003 puis mon master en 2006), mais j’avais commencé à faire un peu de PHP avant de m’orienter vers une formation en informatique. J’ai plaisir à croire que “des jeunes” suivent ce même type de chemin, où ils ont le plaisir de découvrir la programmation par eux-même. Et je n’oublie pas que, en parallèle, de nombreux “non informaticiens” ou “non développeurs” ont besoin de (et souhaitent) mettre en place quelques “petits trucs”.

Ceci dit, des langages comme C ou C++ dans le cadre d’une formation ont aussi leurs avantages : ils sont moins souples et moins permissifs que PHP, mais ça peut aider à faire entrer de bonnes habitudes en tête — par exemple, forcer les étudiants à apprendre à gérer la mémoire est une très bonne chose d’un point de vue pédagogique (passer de langages où tu dois tout faire toi-même à des langages managés me semble plus facile que l’inverse).


Si je puis me permettre : j’aime beaucoup ta conclusion :

Après peut être que c’est aussi à nous (devs PHP) a retrousser nos manches et a aller voir comment ça se passe sous le capot et à apporter notre contribution, ça ne peut qu’être bénéfique à tout le monde au final.

Absolument !

De ce qu’en disent certains qui y sont passés (et, pour certains, n’y sont plus retournés), la vie sur internals@ n’est pas facile tous les jours (je n’y poste moi-même pas, donc je me sens moins “concerné” par certains échanges un peu houleux), mais participer au développement du langage est probablement, effectivement, la meilleure façon de le faire évoluer !

Ce post n'est pas ouvert aux nouveaux commentaires (probablement parce qu'il a été publié il y a longtemps).