Réponses:
Je peux dire avec une certitude à environ 99,9999% que WordPress ne deviendra jamais complètement OOP dans la future version, dont le moindre n'est pas que le sujet soit revenu à maintes reprises sur la liste des pirates informatiques et que les membres de l'équipe centrale n'ont exprimé aucun intérêt pour Ce faisant.
Quand je regarde mon expérience personnelle avec la programmation et l'enseignement de la POO à partir de 1990 environ, je suis d'accord avec l'équipe de base et je pense qu'une POO complète serait une erreur. Bien que j'aie déjà été un fanatique de la POO et que je pensais que la POO était une panacée, j'ai depuis lors pensé qu'elle avait sa valeur dans certains contextes mais dans d'autres contextes, elle gênait.
L'un des plus gros problèmes que j'ai rencontrés avec la POO est qu'il oblige le développeur à créer une structure bien avant que le développeur ne comprenne réellement ce que devrait être cette structure, ce qui conduit alors au problème fragile de la classe de base .
Bien sûr, pour certains aspects de WordPress, la POO a beaucoup de sens et si vous étudiez le noyau, vous trouverez de telles classes; Widget, List_Tables (en 3.1) , etc.
À ce stade, je suis heureux de travailler avec WordPress dans un paradigme principalement non-OOP et je pense que s'il avait été pur, OOP WordPress n'aurait jamais gagné ce qui suit. Pourquoi? Parce que la POO aurait soulevé la barre de la complexité pour les futurs développeurs de thèmes et de plugins WordPress, et cela aurait probablement abouti à une application qui n'était pas suffisamment flexible pour évoluer alors que l'équipe principale en apprenait davantage sur les besoins de ses utilisateurs par le passé. 6 ans.
FWIW.
Beaucoup de composants WP sont réécrits dans le code OOP à chaque nouvelle version, et les nouveaux composants ont tendance à en faire usage (par exemple la WP_Customizerchose). Mais si vous demandez si WP changera son architecture en une architecture entièrement orientée objet - alors non, il n'y a actuellement aucune information suggérant une telle chose.
Je n'irais pas si loin pour dire que cela ne se produira jamais, mais il est peu probable que cela se produise dans un proche avenir, et probablement pas à cause du problème de "classe de base" :)
Tout d'abord, il n'y a que des inconvénients à utiliser du code procédural sur la POO pour une application CMS comme WordPress, simplement parce que ces applications sont destinées à être étendues via des plugins. L'ajout d'un mélange de fonctions et de variables globales ne facilite pas du tout cela. Au moment où WP a été écrit, personne n'aurait pu prédire ce que WP allait devenir et de nombreux mauvais choix ont été faits. Maintenant, c'est assez difficile à rattraper, car la plupart des plugins et des thèmes cesseraient de fonctionner correctement. L'implémentation d'une énorme couche de compatibilité pour éviter cela ralentirait probablement WP et ajouterait encore plus de confusion parmi les développeurs. Pensez également à l'objectif - faciliter la vie des développeurs, au détriment des utilisateurs?
Si cela peut vous aider - une très vieille discussion sur les pirates informatiques, mais toujours pertinente pour ce sujet, et une idée proposée par la communauté, désormais étiquetée "territoire du plugin". Je n'ai pas remarqué d'autre activité dans ce sens récemment.