Nouvelle branche de PHP : P++, oserez-vous encore dire que PHP est un langage faiblement typé ?

Résumé : Rasmus Lerdorf, le fondateur du langage PHP, est né en 1968 et a 51 ans cette année. Il a publié PHP 1.0 en 1995 sous le nom de Personal Home Page Tools. Sa gloire s'est estompée avec le déclin de Yahoo dans les recherches.

En 1997, les programmeurs israéliens Zeev Suraski et Andi Gutmans ont rejoint le développement du langage PHP de Zend Company et ont publié PHP 3, PHP 4, PHP 5. Notez qu'il n'y a pas de PHP 6, et maintenant PHP 7. Zeev Suraski, né en 1975, travaille chez Zend depuis 20 ans. C'est peut-être parce que je ne trouve pas la direction du développement dans le domaine du langage, de l'architecture et du travail en bibliothèque.

Il y a quelques jours Zeev Suraski a annoncé sa démission de Zend L'industrie a été assez surprise Frère Niao, développeur d'optimisation PHP 7, a déclaré que c'était quelque chose qui avait été fait. prévu depuis longtemps. Il s'avère que Zeev Suraski a démissionné parce qu'il voulait faire du P++. Alors, qu'est-ce que le P++ ? Il a répondu via « Idée P++ : FAQ » et l'auteur a traduit le texte intégral.

Traduction originale :

Ceci est une liste de diffusion pour internals@(internals@ : développeurs internes PHP. Ici, questions fréquemment posées (FAQ) des clarifications sur les idées proposées dans des éléments externes (généralement utilisés pour soumettre des RFC et des notifications de publication), qui tentent de résoudre de nombreux problèmes soulevés à plusieurs reprises lors des discussions ultérieures.

Remarque : P++ est un nom de code temporaire et peut changer à l'avenir.

Que se passe-t-il ?

Essayons de condenser le long contenu des e-mails en quelques points :

1 Il y a deux grands camps dans le monde PHP. Le premier aime généralement la dynamique de PHP, avec un fort biais BC (BC : Backward Compatibility, aussi appelé rétrocompatibilité, compatible avec les versions antérieures, c'est-à-dire que le logiciel mis à jour doit prendre en compte la compatibilité des anciennes versions. Par exemple, Word of Office 2019 utilise le format de fichier .docx par défaut, mais il peut également ouvrir le format .doc d'Office 2017/2013/2010, voire 2003. Le concept relatif s'appelle FC, qui signifie Forward Compatibility, qui est également compatible avec les versions ultérieures. appelé compatibilité ascendante, c'est-à-dire que le logiciel mis à niveau prendra en compte la compatibilité future, il s'agit généralement d'une certaine interface et convention dans le logiciel qui sera toujours suivie à l'avenir, qui peut atteindre une compatibilité ascendante), avec un accent particulier sur la simplicité, et une autre préférence est de le réduire. Se débarrasser du bagage et avoir un langage plus strict avec des fonctionnalités de niveau plus élevé et plus complexes.

2. Il n’y a pas de « bien » ou de « mal » ici. Les deux genres sont valables et ont des adeptes très engagés. Cependant, créer un langage qui s'adresse aux deux camps est un défi, qui est une source constante de débats sur les internals@.

3. La proposition est de créer un nouveau dialecte PHP (nom de code P++) qui coexiste avec PHP mais n'est pas lié par la philosophie historique derrière le langage. En d'autres termes, ce nouveau dialecte peut être de nature plus restrictive, il peut être plus audacieux en éliminant la compatibilité ascendante et en supprimant les éléments considérés comme des « bagages » (comme les balises courtes), et en ajoutant des fonctionnalités plus complexes, notamment celles qui sont bien adapté aux langages strictement typés sans introduire les mêmes complexités que les dialectes PHP.

4. Ce n'est pas une branche de code PHP. La base de code sera la même et les développeurs qui y travailleront seront les mêmes. La plupart du code est le même. Seuls les points spécifiques de différence entre les deux dialectes seront mis en œuvre différemment. C'est un peu similaire à ce que strict_types a fait dans PHP 7, mais à plus grande échelle.

Allons-nous vraiment faire cela simplement parce que certaines personnes ne peuvent pas abandonner les balises courtes ?

Cela n'a rien à voir avec les balises courtes, "Dépréciation des balises courtes RFC (RFC : Request for Comments, ajout de fonctionnalités linguistiques et méthodes standardisées de gestion des changements. Habituellement, lorsque de nouvelles fonctionnalités sont ajoutées, de nouvelles Les fonctionnalités sont soumises aux RFC et des exemples sont donnés. Une fois que le comité de changement aura évalué et approuvé, le langage sera intégré dans le code source d'implémentation et incorporé dans la nouvelle version)" n'est pas la principale motivation de cette idée. Le but de cette proposition est d'être plus ambitieuse, c'est de donner une vision claire pour PHP et d'espérer enfin résoudre les tensions entre les deux camps en donnant aux deux camps ce qu'ils veulent.

Pourquoi forker PHP ?

Ceci n'est pas une fourchette. La base de code sera exactement la même, elle sera développée par les mêmes personnes. Les binaires seront exactement les mêmes, si vous installez PHP vous installerez également P++ et vice versa. Le même binaire exécutera des applications PHP, P++ ou combinées PHP/P++.

Bien qu'il ne soit pas clair comment un fichier est "marqué" comme fichier P++, il peut s'agir d'une marque spéciale en haut du fichier, comme ceci :

<?p++?>
<?php &#39;Hello, world!&#39;; ?>

De plus, nous pourrions trouver que L'ensemble de l'espace de noms est marqué comme P++, le framework n'a donc pas besoin de marquer explicitement chaque fichier individuel comme P++.

Cela signifie que notre charge de travail de développement a doublé et que le nombre de contributeurs en internals@ est déjà faible. Comment pouvons-nous y faire face ?

Heureusement, ce n’est pas censé être ainsi (doubler la charge de travail). La grande majorité du code sera partagée entre le mode PHP et le mode P++ – à la fois le code source et le runtime.

Que le fichier en cours d'exécution soit un fichier PHP ou P++, les structures de données, les sous-systèmes clés, les extensions, les interfaces du serveur Web, OPcache et tous les autres codes seront exactement le même code. La seule surcharge de développement supplémentaire sera la différence entre PHP et P++.

En effet, cela signifie que nous devons maintenir deux versions de certains extraits de code, et nous aurons des instructions if() ici et là, puisque P++ peut avoir des contrôles supplémentaires par rapport à PHP. Cependant, si nous voulons passer à une version plus stricte de PHP, ces éléments doivent quand même être introduits. De plus, même ceux du camp strict ne recommandent pas de passer à une future version stricte sans fournir de chemin de migration - en fait, l'effort impliqué dans cette approche est similaire à presque n'importe quelle autre approche.

Lorsque nous passons à PHP 8/9 plus strict, pourquoi ne pas simplement développer une version de maintenance à long terme de PHP 7.4 maintenue en permanence ?

Cette approche pose de nombreux problèmes. Même si nous ignorons le fait que cela laisse en suspens l’énorme camp des préférences dynamiques – sans aucune mise à jour des fonctionnalités ou des performances, cela n’est pas pratique du point de vue des efforts de développement. Ceci est différent de cette proposition, qui signifie en fait un fork de facto.

Dois-je choisir entre PHP et P++ ?

Oui et non. Comme mentionné ci-dessus, lorsque vous installez l'un, vous avez l'autre, donc en ce qui concerne les applications, vous pouvez exécuter les deux dialectes sur un seul serveur. Cependant, dans la pratique, les projets et les individus peuvent souvent choisir et normaliser l’un ou l’autre, comme dans le cas des types stricts.

Puis-je mélanger PHP et P++ dans la même application ?

Oui. Bien que nous devions déterminer le mécanisme précis, la spécification du code PHP ou P++ se fera au niveau du fichier et non au niveau de la requête. Une seule exécution (requête) peut charger de nombreux fichiers différents, qui peuvent provenir des deux dialectes. Le code des fichiers PHP se comportera comme une sémantique PHP - et le code des fichiers P++ se comportera comme une sémantique P++. Ceci est également similaire à strict_types.

Bien que cela puisse paraître gênant au début, il peut y avoir des cas d'utilisation très pratiques. Par exemple, une application PHP utilise un framework uniquement P++, et vice versa. Pour ceux qui connaissent le C et le C++, c'est quelque peu similaire.

Est-ce que cela signifie que PHP n'évoluera plus ? Toutes les nouvelles fonctionnalités arriveront-elles dans P++ ?

Non, cela signifie simplement que ça ira dans un sens différent. La rigueur et les fonctionnalités liées au type ne peuvent être disponibles qu'en P++ et ne peuvent être utilisées que dans les fichiers P++. Le biais de compatibilité ascendante restera en PHP (cela ne signifie pas que la compatibilité ascendante ne sera jamais rompue, mais simplement qu'il doit y avoir un bon retour sur investissement pour chacun de ces cas).

Cependant, des fonctionnalités sans rapport avec cela, telles que l'amélioration des performances du moteur (telles que JIT), le développement d'extensions ou de nouvelles fonctionnalités liées à l'async, sont disponibles pour PHP et P++.

Quels sont les avantages de cette méthode ?

Cette méthode présente de nombreux avantages. Premièrement, cela constitue une bonne solution pour les deux camps d’internes@. Ceux qui préfèrent la nature dynamique de PHP peuvent le conserver, tandis que ceux qui préfèrent un langage plus strictement typé peuvent également l'obtenir sans aucune restriction PHP. L’alternative est un jeu à somme nulle, dans lequel une victoire d’un camp est une défaite pour l’autre, et vice versa.

En plus de concevoir une bonne solution technique qui nous permet de prendre en charge l'ensemble de notre public avec un minimum d'effort, cela mettrait également fin à une source clé de discorde sur les internes@ ces dernières années.

Enfin, même si la plupart des lecteurs de ce document sont probablement des techniciens, il convient de noter que démarrer P++ à partir d'un nouveau point de départ, quel que soit le passé, peut présenter d'énormes avantages en termes de positionnement et de marque. Les entreprises, les responsables du développement et les développeurs individuels qui n'utilisent pas PHP sont plus susceptibles de remarquer l'introduction de P++ que l'introduction de PHP 8.0 ou PHP 9.0.

Ne risquons-nous pas de diviser la base d’utilisateurs ?

D'une certaine manière, nous le sommes. Mais ce n’est pas un défaut de l’idée, mais une manifestation de la réalité qui existe déjà.

Comme mentionné ci-dessus, beaucoup de gens aiment la nature dynamique de PHP et hésitent à essayer de le rendre de plus en plus orienté type.

Pendant ce temps, un autre groupe de personnes regarde PHP et se demande : « Pourquoi est-ce que ça devient si lent que je vais enfin abandonner cette absurdité dynamique ? »

Il n’y a pas de bien ou de mal ici. Les deux points de vue sont valables. Lorsque nous avons examiné les solutions possibles pour concilier ces deux points de vue contradictoires, il n'y en avait pas beaucoup :

1. Tenez-vous-en au PHP dynamique. Cela ne sera pas accepté par les partisans d’un langage plus strict.

2. Développer vers un PHP strict. Les partisans des langages dynamiques n’accepteront pas cela.

3. Forkez la base de code. Quelle que soit la manière dont cela est fait, il s’agit d’une option de perte nette pour tous les participants. Il n'y a aucun avantage technique à faire cela, et même si nous le voulions (ce qui n'est pas le cas), nous n'aurions pas suffisamment de contributeurs pour le faire.

4. Proposez des solutions créatives pour répondre aux besoins des deux publics. C'est ce que tente de faire cette proposition. Il assure une interopérabilité permanente entre les deux dialectes tout en gardant l’unité du projet lui-même. Même si cela présente un certain degré de fragmentation, cela reste le minimum possible pour répondre aux principaux besoins de chacun.

En quoi cela diffère-t-il de l'idée de ​​​​Nikita (un intervenant sur les internes@ qui a proposé d'ajouter des fonctionnalités à la version. D'ailleurs, la série télévisée américaine "Nikita" vaut la peine d'être regardée .) version?

Il existe de nombreuses similitudes entre ces deux idées, mais il existe également des différences substantielles. Veuillez noter que ceci est basé sur une compréhension limitée de la méthodologie de version, de sorte que certaines parties peuvent être manquantes, inexactes ou incorrectes.

1. Dans cette proposition, il y a un objectif clair de conserver le PHP typé dynamiquement actuel en tant que dialecte égal à long terme, entièrement pris en charge. L'approche de publication traite le comportement actuel comme « hérité ». Cela signifie qu'il peut être déconseillé (utilisé), puis obsolète et supprimé à un moment donné.

2. La stratégie de lancement est complètement différente. La proposition P++ vise à se concentrer d'abord sur les éléments de rupture de compatibilité tels que les opérations strictes, les modifications de la logique de conversion de type, la gestion des index de tableau, l'exigence de déclarations de variables, etc., et vise à les fournir dans le premier numéro de P++. Le but de ceci est de permettre aux nouveaux projets/frameworks de repartir à zéro sans savoir qu'ils devront peut-être procéder à une réécriture majeure dans un an ou deux lorsque d'autres changements de compatibilité seront introduits. La proposition de gestion des versions ne semble pas avoir un tel objectif, mais vise plutôt à ajouter/modifier progressivement des éléments en PHP.

3. Liée à l'approche de déploiement, l'approche de versionnement ne permet pas seulement deux dialectes, mais un nombre illimité de dialectes. Nous pouvons avoir un dialecte PHP2020, ainsi qu'un dialecte PHP2022 et un dialecte PHP2027. Si nous les gardions tous, cela pourrait en fait augmenter la complexité de notre maintenance.

4. La proposition mentionne également différentes stratégies de rupture de compatibilité ascendante pour PHP par rapport à P++ (conservateur ou agressif), alors que le schéma de gestion des versions peut ne pas aborder ce sujet du tout.

5. La proposition de version n'est pas exactement la même en terme de positionnement/marketing que cette proposition.

Il est important de noter que ces deux idées ne s’excluent pas nécessairement mutuellement. Nous pouvons introduire P++ et utiliser des versions pour l'améliorer, surtout s'il s'avère difficile d'intégrer tous les changements importants dans la première version de P++.

Quels sont les défis ?

Les défis n'ont pas manqué avant de pouvoir exécuter notre première application P++.

1. Nous avons besoin de soutien. Cela signifie que les gens des deux côtés de l'allée doivent abandonner leur rêve de rendre PHP entièrement dynamique ou entièrement typé, et ignorer ceux qui pensent différemment d'eux. Cela semble être un défi très important.

2. Pour réussir, la première version de P++ devrait gérer toutes, ou du moins la plupart, les changements de compatibilité de PHP afin que les développeurs qui changent (potentiellement assez douloureusement) n'aient pas à revoir/complètement refactoriser leur code. Certains ont exprimé leur inquiétude quant au fait qu'en raison des capacités limitées de nos développeurs, ils pourraient être trop optimistes et incapables de publier un seul numéro. Une fois que nous avons une meilleure idée de l’objet de la liste, nous devons l’évaluer. Notez que cela ne signifie pas que nous devons implémenter toutes les idées que nous pourrions avoir pour P++ dans le premier numéro, mais simplement que nous devons donner la priorité aux éléments qui déclencheront de nombreuses réécritures de code par l'utilisateur final et essayer cela avant que notre premier numéro ne les traite. .

3. Bien sûr, le plus difficile est de trouver un nom raisonnable pour ce nouveau dialecte.

Recommandations associées :

1. Pourquoi php est-il le meilleur langage au monde ?

2 PHP n'a plus dix ans. ancien

3. PHP 7.4 devrait sortir en décembre 2019

4 2019Pourquoi continuerons-nous à le faire. utiliser PHP ?

5. Pourquoi les programmeurs piratent-ils PHP ? Le site Web chinois PHP a quelque chose à dire !