IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un développeur de PHP propose un langage fortement typé, le P++,
Avec des fonctionnalités plus avancées

Le , par Bill Fassinou

143PARTAGES

28  3 
Zeev Suraski, un développeur de PHP a proposé il y a quelques jours un langage frère au PHP. Baptisé P++, comme une incrémentation du PHP simple comme cela a été le cas avec le C et le C++, le nouveau langage sera un langage plus strict avec un bagage réduit et des fonctionnalités plus avancées et un langage fortement typé. P++ ne devrait pas être considéré comme un fork de PHP, car, selon lui, cela va ressembler un peu à ce qui a été fait avec strict_types dans PHP 7, mais seulement à une plus grande échelle.

Selon les contributeurs internes du langage, les raisons qui justifient cette initiative sont multiples, mais il en existe une qui est beaucoup plus importante. En effet, ces derniers ont expliqué qu’il existe deux grandes écoles de pensée dans le monde de PHP. La première aime à peu près le langage PHP dans sa forme actuelle, c’est-à-dire dynamique, rétrocompatible avec un accent mis sur la simplicité. L’autre préfère un langage plus strict, avec un bagage réduit et des fonctionnalités plus avancées ou plus ou moins complexes. Il n'y a pas de « bien » ou de « mal » à ça. Les deux écoles de pensée sont valables et ont un très grand nombre d'adeptes.

Seulement, selon l’équipe de développement de PHP, il est difficile de concevoir un langage qui s'adresse à la fois à ces deux foules en même temps, ce qui est une source constante de conflits au sein même des contributeurs internes du langage. D’un autre côté, cela peut également être dû au fait que le PHP est fortement critiqué sur sa forme non typée. Ainsi, selon certains, il n'est absolument pas adapté pour créer des applications plus robustes. Pour ces derniers, des applications se font en C++, en Delphi, à la limite en Java, mais absolument pas en langage de script. PHP est un langage de script orienté Web et n'a pas les outils pour faire autre chose.


À ce titre, ils ont expliqué que le PHP commence à avoir des outils pour créer des applications plus sûres (compilation classique, librairie GTK) et ses outils sont très pratiques quand on n'a pas le temps d'apprendre un autre langage. Cependant, le langage qui serait le plus adapté dans ces cas devrait avoir accès aux ressources et fonctions du système. Il doit également posséder un typage fort des variables, sans quoi à chaque opération, l’on est obligé de passer par une interprétation ou une retraduction d'où des pertes de performances inutiles. Ces besoins seront peut-être comblés à l’avenir avec la proposition de P++.

P++ n'est pas un fork de PHP. La base de code sera identique, elle serait mise à la fois ensemble et développée par les mêmes personnes. La grande majorité du code serait identique. L'équipe a informé que seuls les points de différence spécifiques à chacun des deux langages auront des implémentations différentes. Cela va ressembler un peu à ce qui a été fait avec la directive strict_types dans PHP 7, seulement à une plus grande échelle. Les fichiers binaires seront identiques. Ainsi, si vous installez PHP, vous auriez installé P++ et vice versa. Le même binaire exécutera vos applications PHP et P++ ou combinées PHP/P++.

Cela ne signifie pas que l’équipe va doubler ses efforts de travail, car la grande majorité du code sera partagée entre le mode PHP et le mode P++, à la fois en code source et à l'exécution. Les structures de données, les sous-systèmes de clés, les extensions, les interfaces de serveur Web, OPcache, et presque tout le reste seront le même code en cours d’exécution, que le fichier en cours d’exécution soit en PHP ou en P++. Les seuls coûts supplémentaires de développement seront les zones de différence spécifiques entre PHP et P++. Il sera également possible de faire chevaucher les deux langages.

Vous pourriez mélanger et assortir PHP et P++ dans la même application. Selon l’équipe de développement, cela peut sembler étrange au début.
Néanmoins, il pourrait y avoir à la longue des cas d'utilisation très pratiques pour cela. Pour ceux qui sont familiers avec le C et le C++, c’est un peu la même chose. À présent, notez que l’arrivée de P++ ne signifie pas que PHP n’évoluera plus ou si toutes ses fonctionnalités iront à P++. Cela veut juste dire que les deux langages évolueront séparément. Les nouvelles fonctionnalités plus strictes et liées au type vont probablement aller uniquement à P++, et ne seront disponibles que dans les fichiers P++.

La partie dynamique qui met l’accent sur la simplicité restera en PHP. Toutefois, des fonctionnalités non liées, telles que l'amélioration des performances du moteur (JIT, par exemple), les développements d'extensions ou de nouvelles fonctionnalités liées à l'async, seront disponibles pour PHP et P ++. D’après les explications fournies par l’équipe, cette approche présente de nombreux avantages. Premièrement, cela donne aux deux camps, une bonne solution à leurs aspirations.

En d’autres termes, ceux qui préfèrent la nature dynamique de PHP peuvent le conserver, tandis que ceux qui préfèrent un langage plus typé parviendront à l’obtenir sans être soumis à aucune limitation de PHP. L'alternative à cela est un jeu à somme nulle, où le gain d'un groupe est la perte de l'autre, et vice versa. Selon l’équipe, en plus d’être une bonne solution technologique qui va permettre d’apporter un effort minimal à l’ensemble de la communauté, cela pourrait également mettre fin aux sources de discorde qui ont existé au cours des dernières années parmi les développeurs internes du langage.

Enfin, l’équipe a annoncé que cette initiative présente un certain nombre de défis à relever. De plus, pour l’instant, elle ne dispose d’aucune proposition sur la façon dont elle va marquer un fichier en tant que fichier P++. Il s'agira probablement d'une sorte d'en-tête spécial en haut du fichier, mais rien n'est encore décidé. En outre, elle a annoncé qu’elle peut trouver des moyens pour marquer les espaces de noms en P++, afin que les frameworks n'aient pas à marquer explicitement chaque fichier individuel en tant que P++. Pour en savoir plus sur le sujet, vous pouvez consulter la FAQ mise en place par l’équipe sur le wiki du langage.

Dans la communauté, certains apprécient cette initiative de l’équipe de développement du langage, mais par contre, d’autres pensent que maintenir deux projets distincts en même temps ne serait pas une chose profitable. « Personnellement, j’aime une approche plus stricte. Je n'aime pas le fait que vous puissiez combiner PHP et P++. Cela ne fera qu'ouvrir la porte à des bases de code encore plus compliquées. Beaucoup d'entre nous veulent avancer avec le langage et cesser d'être retenus en permanence par les problèmes que pose la rétrocompatibilité du langage », a déclaré l’un d’eux.

« Vu que le PHP a atteint maintenant les 20 ans, je pense qu'il ne serait pas aberrant de proposer une version de PHP qui casserait la rétrocompatibilité pour cause de nouvelles fonctionnalités génialissimes. Bref, il faut préparer les 20 prochaines années et ce n’est pas en traînant les comportements vieux d'il y a 20 ans que ça va se faire », a ajouté un autre.

Source : Wiki PHP

Et vous ?

Quel est votre avis sur le sujet ?
Selon vous, le P++ est-il une bonne ou mauvaise initiative ? Pourquoi ?
Êtes-vous déjà satisfaits de PHP tel qu'il est ou souhaiteriez-vous un langage plus typé ?
Les développeurs de PHP devraient-ils renoncer à la rétrocompatibilité du langage pour proposer un langage plus compétitif selon vous ?
P++ pourra-t-il tenir les fruits de ses promesses ?

Voir aussi

PHP 8 va proposer un compilateur Just In Time qui devrait produire une amélioration des performances en vitesse

PHP 7.4 devrait être rendu disponible vers la fin de cette année. Voici un aperçu des nouveautés qui pourraient y figurer

PHP 7.3 est disponible en version stable : un aperçu des nouveautés du langage de programmation côté serveur

PHP 7.2 est disponible en version stable avec la bibliothèque de cryptographie Sodium et d'autres améliorations et nouvelles fonctionnalités

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 17/08/2019 à 17:26
Citation Envoyé par Madmac Voir le message
Just'une question pour les fanatiques du typage fort? Cela vous arrive combien de fois, par année, d'envoyer le mauvais type à une fonction, pour de vrai ?

Je conçois que lorsque l'on apprend un langage, le type peut-être une béquille importante. Mais par la suite, ce typage devient plus un poids qu'une commodité.
L'un des plus gros avantages du typage statique est que c'est une sorte de documentation pour laquelle on a la garantie qu'elle est à jour. Par exemple, quand on s'apprête à modifier le code d'une fonction existante, on a souvent envie de savoir quelles sont les opérations disponibles pour ce qui est passé en paramètre. Pour le savoir, c'est beaucoup plus rapide quand on a un contrôle sur le type que quand on doit chercher récursivement dans le code appelant pour savoir quels sont les types concrets possibles.

Le typage statique sert dès la lecture du code, pas seulement quand on fait une étourderie en modifiant le code qui aurait été probablement détectée indirectement plus tard en lançant les tests unitaires.

Remarque importante : en début de vie d'un logiciel, celui qui a écrit le code from scratch ne sera pas forcément très gêné par une absence de typage, car il connaît déjà bien le code appelant, puisque c'est lui qui l'a écrit. Mais, des années plus tard, quand le code aura bien grossi, les malheureux qui reprendront ce code n'auront pas le luxe d'étudier ce code tout entier avant de commencer à le modifier. À ce moment, sans typage, le code sera chiant à maintenir.
9  0 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 12/08/2019 à 15:30
Citation Envoyé par Bill Fassinou  Voir le message
« Vu que le PHP a atteint maintenant les 20 ans, je pense qu'il ne serait pas aberrant de proposer une version de PHP qui casserait la rétrocompatibilité pour cause de nouvelles fonctionnalités génialissimes. Bref, il faut préparer les 20 prochaines années et ce n’est pas en traînant les comportements vieux d'il y a 20 ans que ça va se faire », a ajouté un autre.

L'autre, c'est moi
C'est à 99% exactement ma prose tirée d'une autre discussion sur le forum DVP.

Pour l'évolution du PHP fortement typé, je suis pour à fond. Savoir ce que l'on manipule est un tel confort qu'à mes yeux c'est un must have.
Depuis la version 7, j'ai converti absolument tous mes codes au typage fort partout où c'était possible. Et cela m'a permis de supprimer des centaines de lignes de code rien que pour s'assurer du type et autre conversion de ce qui était manipulé.
Bref, même les tests unitaires s'en sont trouvés sacrément réduits.
La couleur était déjà annoncée avec l'arrivée de PHP 7.4 qui allait permettre de typer les attributs des classes :
Code php : Sélectionner tout
1
2
3
4
class Foo { 
    private string $foo; 
    private int $nb; 
}
7  1 
Avatar de
https://www.developpez.com
Le 12/08/2019 à 20:49
Citation Envoyé par bouchery Voir le message
Je constate que la grande majorité des personnes qui souhaitent que PHP soit "full-strict" manquent cruellement de pragmatisme et doivent se placer bien haut sur la montagne de Dunning-Kruger
"L’effet Dunning-Kruger ... est un biais cognitif selon lequel les moins qualifiés dans un domaine surestiment leur compétence."

Donc les gens demandent qu'un compilateur les aide à vérifier le typage de leur code parce qu'ils se sur-estiment... Ca me parait logique
6  0 
Avatar de Eric30
Membre actif https://www.developpez.com
Le 12/08/2019 à 19:38
Citation Envoyé par bouchery Voir le message
Je constate que la grande majorité des personnes qui souhaitent que PHP soit "full-strict" manquent cruellement de pragmatisme et doivent se placer bien haut sur la montagne de Dunning-Kruger .
Parce que tu te considères humble en disant cela peut-être?

Citation Envoyé par bouchery Voir le message
On sait faire de très belles choses sans typage strict, ni même POO. Un peu d’ouverture et d'humilité que diable (même si j'aime le typage fort).
Mais personne ne dit le contraire.
C'est juste que le typage strict permet d'être moins verbeux et de ne pas passer trop de temps à rajouter du code pour contrôler le type de données. Il y a aussi une forte notion de sécurité... et de pragmatisme.
5  0 
Avatar de _Thomas
Membre confirmé https://www.developpez.com
Le 13/08/2019 à 16:41
Je n'ai pas forcément d'avis sur la question (pas forcément le recul ni les compétences nécessaires pour juger les avantages/inconvénients défendus par les uns et les autres), mais je trouve pertinent de partager cette conférence récente du créateur du langage :



Il montre assez bien (je trouve) à quel besoin PHP a répondu quand il a été inventé, ça permet ainsi de comprendre d'où viennent les "faiblesses ou bizarreries" de PHP, mais aussi vers quels horizons se dirigent le langage à l'avenir et la prétention (ou non) de ce dernier sur tel ou tel sujet particulier.
4  0 
Avatar de Eric30
Membre actif https://www.developpez.com
Le 12/08/2019 à 15:34
D’un autre côté, cela peut également être dû au fait que le PHP est fortement critiqué sur sa forme non typée. Ainsi, selon certains, il n'est absolument pas adapté pour créer des applications plus robustes.
Le typage scrict est activable depuis fin 2015 et la sortie de PHP7.0. Si les gens décident de coder comme des cochons, il faut rappeler que rien ne les y oblige.
Quant aux applications "non robustes", cela fait rire et relève plus de l'ignorance. Il y a de sacrés "monstres" qui tournent sous PHP, parmi les sites les plus visités au monde (dans le domain de l'adulte par exemple )
3  0 
Avatar de
https://www.developpez.com
Le 13/08/2019 à 18:44
Citation Envoyé par Matthieu76 Voir le message
Pourquoi ne pas directement utiliser un language fortement typé et moderne tel que C# ou Java ?
Sans vouloir troller, si c'était pour passer à des langages modernes ce serait plutôt Kotlin, Scala, Rust ou PureScript.

Et pour répondre à la question : peut-être pour ne pas perdre des années à devoir réapprendre un langage et son écosystème et réécrire toute la base de code.
4  1 
Avatar de NukaCola
Membre à l'essai https://www.developpez.com
Le 14/08/2019 à 17:36
Pour avoir lu les discussions sur le P++ (https://externals.io/), quasiment tous (si ce n'est tous) les autres développeurs de PHP sont contres. Sans compter les utilisateurs.

Ils viennent également d'ouvrir un sondage, et pour l'instant, l'avis général est clair : 0 - 13 en faveur du non en 20 min
https://wiki.php.net/rfc/p-plus-plus
3  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 12/08/2019 à 17:02
Plus qu'un autre langage , il faudrait "simplement" sur un PHP 9 ou 10 oser casser des choses, mais pour ça encore faudrait il que tout le monde soit d'accord au sein des contributeur ... et là c'est pas gagné.

On pourrait imaginer une transition en douceur avec par exemple un PHP 9 qui introduit un type fort complet mais optionnel , en gros on aurait un type par défaut "any" si on ne spécifie pas de type.
Puis un PHP 10 qui impose le typage fort, qui supprime toutes les api procédural, qui normalise les paramètres , etc ...

PHP à très fortement progresser en performance , il faut maintenant arriver à évincer les petits défauts connus de tout le monde.

Quoi qu'il en soit il ne sera jamais possible de faire une transition brutale en quelques mois. Ça va prendre du temps.
3  1 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 13/08/2019 à 10:22
@archqt

Oh le gros troll en béquilles que voilà
Ce n'est pas parce que la technologie est interprétée qu'on doit se passer de la possibilité de typer ses variables.
Il y a quand même une gigantesque différence entre l'interprété et le compilé.

Facebook avait essayé d'avoir une partie de son site en version compilée et après moult essais a dû faire machine arrière, les contraintes étaient trop fortes pour du web (HipHop).
Ils se sont rabattus sur une autre approche HHVM qui est un compilateur JIT qui offre des possibilités d'optimisations que le compilé ne peut pas faire. Et du coup les perfs se sont drastiquement améliorées.

Le compilé n'est pas forcément le plus véloce dans tous les cas de figures.
2  0