O WordPress se tornará completamente OOP?

Eu posso dizer com cerca de 99,99999% de certeza que o WordPress nunca se tornará completamente OOP na versão futura, não menos do que é que o tópico surgiu várias vezes na lista de wp-hackers e os membros da equipe principal expressaram não há interesse em fazê-lo.

Quando observo minha experiência pessoal com programação e ensino de POO a partir de 1990, concordo com a equipe principal e acho que a POO completa seria um erro. Embora eu já tenha sido uma panóplia e pensado em OOP, eu já passei a acreditar que ela tem seu valor em alguns contextos, mas em outros contextos isso atrapalha.

Um dos maiores problemas que eu encontrei com o OOP é que ele força o desenvolvedor a assar em estrutura muito antes que o desenvolvedor realmente entenda o que essa estrutura deve ser, o que leva a the frágil problema da classe base .

É claro que, para aspectos selecionados do WordPress, a OOP faz muito sentido e, se você estudar o núcleo, encontrará essas classes; Widget , List_Tables (em 3.1) , etc.

Neste ponto, estou feliz em trabalhar com o WordPress em um paradigma não-OOP e acho que, se tivesse sido puro OOP, o WordPress nunca teria ganhado o seguinte. Por quê? Como a POO elevou o nível de complexidade para futuros criadores de plugins e criadores de plug-ins do WordPress, o que provavelmente resultaria em um aplicativo que não era flexível o suficiente para evoluir à medida que a equipe principal aprendesse mais sobre as necessidades de seus usuários no passado. 6 anos.

FWIW.

    

Muitos componentes do WP são reescritos no código OOP a cada nova versão, e novos componentes tendem a utilizá-lo (por exemplo, a WP_Customizer thing). Mas se você está perguntando se o WP vai mudar sua arquitetura para uma arquitetura totalmente orientada a objetos - então não, não há atualmente nenhuma informação que sugira tal coisa.

Eu não iria tão longe para dizer que isso nunca acontecerá, mas é improvável que isso aconteça no futuro próximo, e provavelmente não por causa do problema da "classe-base":)

Primeiro de tudo, há apenas desvantagens em usar código procedural sobre OOP para um aplicativo CMS como o WordPress, simplesmente porque esses aplicativos devem ser estendidos através de plugins. Jogar em uma mistura de funções e variáveis globais não facilita isso. Na época em que o WP foi escrito, ninguém poderia prever o que o WP se tornaria e muitas más escolhas foram feitas. Agora é muito difícil recuperar o atraso, porque a maioria dos plug-ins e temas pararia de funcionar corretamente. A implementação de uma enorme camada de compatibilidade para evitar isso provavelmente reduziria o WP e adicionaria ainda mais confusão entre os desenvolvedores. Pense também no propósito - para facilitar a vida dos desenvolvedores, às custas dos usuários?

Se isso ajudar - uma discussão muito antiga sobre os wp-hackers, mas ainda relevante para este tópico, e uma ideia proposta pela comunidade, agora marcada como " território do plugin ". Eu não notei outra atividade nessa direção recentemente.