La grande question qui se profile à l’horizon, tout au moins pour les développeurs PHP, est de choisir entre deux opportunités d’avenir : soit maintenir la compatibilité arrière et rester un peu coincé aux entournures, soit rompre avec ce passé et moderniser PHP, pour qu’il devienne un langage script comparable à ses grands concurrents.

Il y a quelques mois, Zeev Suraski, l’un des fondateurs de Zend Technology, une compagnie israélienne qui a beaucoup fait pour le développement de PHP, annonçait qu’une nouvelle version de PHP « pourrait » arriver, qui ne serait pas la 8, celle-ci se caractérisant surtout par l’adjonction d’un compilateur « just-in time » pour améliorer ses performances, mais une version dite P++, autour de laquelle les esprits des développeurs se sont fortement échauffés. Surtout dans une période ou de plus en plus de chefs de projets et responsables de TI se posent des questions sur l’opportunité de maintenir PHP en tant que langage de programmation majeur. Aux côtés de Java et de C#, le plus souvent.

L’idée de Suraski, qui ne sera peut-être pas suivie des faits, ou serait intégrée dans une version « normale » de PHP, concerne la fameuse problématique du typage du langage, dynamique et faible, qui constitue pour beaucoup de développeurs, plus un inconvénient qu’un avantage.

En programmation, on dit qu’un langage est fortement typé lorsqu’il garantit que les données manipulées correspondent bien au type que l’on attend.

Alors qu’un langage faiblement typé est beaucoup plus permissif, qui n’impose pas de type à une variable ou la définit (langage dynamique) à l’exécution et pas à la compilation.

Globalement on dira que le typage est fort si le compilateur ou le contexte d’exécution détectent les erreurs de typage. Dans tous les autres cas, il sera dit faible.

A noter, qu’en principe, les transcriptions implicites sont exécutées par l’environnement, sous prétexte, par exemple, qu’une affectation ne serait pas jugée cohérente :

Int var 1, var2;

var1 = var2;

si var2 est une valeur décimale, la transcription implicite ne prendra que la partie entière pour ne pas bloquer le processus. On comprend aisément toutes les catastrophes que ce transtypage implicite peut amener, au gré des exécutions.

Une distinction plus fine sur le typage fort concerne le moment où les types sont décidés, à la compilation (typage statique) ou à l’exécution (typage dynamique).

Des langages tels que OCaml ou Haskell sont des langages à typage fort. C++ et Java sont aussi des langages à typage fort statique, Ruby et Python étant à typage fort, mais dynamique.

A l’inverse, le C est à typage faible statique, alors que JavaScript et PHP sont aussi de typage faible, mais dynamiques.

Bref, on voit à peu près de quoi il s’agit, les développeurs adorant se lancer dans des soliloques infinis sur le sujet. Tout le monde ayant tort et raison à la fois.

Quelle stratégie pour P++

Pour ce qui concerne l’évolution de PHP, on a deux écoles. D’un côté, il y a ceux qui apprécient le langage, justement parce qu’il est simple et dynamique, les autres espérant qu’il évolue vers un formaisme plus rigoureux, plus strict, doté de fonctionnalités avancées, comme celles que l’on trouve sur les langages modernes.

La question est de savoir si les deux point de vue sont conciliables et si l’on ne pourrait pas imaginer une solution, qui ménagerait la chèvre et le chou.

Ce que l’on sait aujourd’hui de P++ ne permet pas de répondre complètement à cette interrogation.

P++, notez quand même l’allusion à C++, comparé à C, est un dialecte de PHP, qui normalement pourrait vivre sa vie parallèlement à celle de PHP, sans qu’il y ait de blocages majeurs.

Les puristes, qui pensent à l’esthétisme du code et à son efficacité, estiment aussi qu’il pourrait constituer un bon prétexte pour le nettoyer de quelques incongruités, telles que celles des « short tags », par exemple.

Il s’git d’une disposition faite pour faciliter la vie des développeurs et qui concerne la délimitation du code que l’interpréteur PHP doit prendre en compte. Normalement les deux balises officielles de début et de fin sont < ?php et ?>, mais il existe des « short tags » plus rapides à écrire, telles que < ? et ?>, < ?= et ?> ou <% et %> .

Le problème est que ces tags courts peuvent provoquer des dysfonctionnements, dans la mesure où ils ne seraient pas reconnus par le serveur, porteur du code PHP.

Ce qui sera le cas si le fichier php.ini comporte un paramètre short_open_tags positionné à off.

Le mieux, en l’occurrence est de se contenter de la forme générique que tous les interpréteurs PHP comprendront.

 

 

 

 

 

 

 

 

 

 

 

Tout l’art des référents PHP que sont Rasmus Lerdorf, à l’origine du langage et Zeev Suraski, fondateur de Zend Technology sera de trouver un compromis entre une évolution radicale de PHP vers des concepts plus modernes et le respect des caractéristiques qui ont fait sa force : simplicité et dynamisme. En quelque sorte ménager la chèvre et le chou.

Le typage faible de PHPHormis ce prétexte donné à un futur « nettoyage » de la syntaxe PHP, la véritable question concerne quand même son typage faible.

En PHP, le type d’une variable est défini par la valeur qui lui est affectée à l’exécution, bien que l’on ait pris soin de la décrire par une déclaration : Int, String, Float, Boolean, Array, Object, NULL ou Resource.

Si l’interpréteur tombe sur une affectation incohérente, il va faire en sorte de l’ « arranger » pour qu’elle devienne conforme à la règle.

Sympathique, mais extrêmement dangereux dans la mesure où on risque de manipuler des données, dont le type ne sera pas celui attendu.

D’une manière générale, le type en PHP est défini à l’exécution :

$var = 10 ; définit implicitement var comme un entier

$total = 240.00 ; décrit total comme une variable flottante.

Mais PHP permet aussi le transtypage explicite (casting) et peut forcer le type d’une variable. Il suffira de préfixer la variable en question par un autre type, placé entre parenthèses, tel que :

$var = 10 ;

Puis $valeur = (double)$var ;

Dans ce cas, l’interpréteur prendra le contenu de $var, qu’il traduira en double et qu’il affectera à la variable $valeur.

Simple, non ? Sauf que dans un typage fort, très sécurisant, le procédé est rigoureusement interdit.

On notera d’ailleurs que déjà dans PHP 7, on a assisté à une première tentative de typage fort avec la directive strict_types = 1, qui impose un typage bien précis, sans dérogations possibles :

< ?php

declare (strict_types=1) ;

function ajouter (int $var1, int $var2) {

return $var1 + $var2 ;

}

on aura une erreur fatale si :

return $10 + $« bonjour » ;

Dialecte ne veut pas dire langage nouveau

Attention, si P++ voit le jour, il ne remettra pas en cause PHP. On l’a déjà signalé, il ne sera qu’un dialecte, avec un peu de sucre syntaxique par ci par là.

Un code P++ pourrait d’ailleurs cohabiter avec du PHP classique, dans la même application. La seule chose que l’on ne sache pas pour l’instant, c’est la manière qui nous permettra de distinguer le code P++ du reste. Sans doute par un en-tête spécifique, mais on n’en sait pas plus.

Pour le reste, on sait que le code sera identique et qu’il conservera les structures de données, les sous-systèmes de clés, les extensions, les interfaces de serveurs Web, OPcache (disposition qui optimise le code et le met en cache dans la mémoire partagée), etc.

Ce ne sera donc pas la révolution, tout au plus une tentative de répondre intelligemment à une question essentielle, la fiabilité des applications, sans laquelle tôt ou tard, PHP serait condamné à disparaître.

Au grand dam, évidemment, des onze millions de programmeurs qui ne jurent que par lui.