Odpowiedzi:
Mogę powiedzieć z około 99,9999% pewnością, że WordPress nigdy nie stanie się całkowicie OOP w przyszłej wersji, a co najmniej ważne, że temat pojawiał się wielokrotnie na liście wp-hackerów, a członkowie podstawowego zespołu nie wyrazili zainteresowania robiąc tak.
Patrząc na moje osobiste doświadczenia z programowaniem i nauczaniem OOP od około 1990 roku, zgadzam się z głównym zespołem i myślę, że kompletne OOP byłoby błędem. Chociaż kiedyś byłem fanatykiem OOP i myślałem, że OOP to panaceum, odtąd uwierzyłem, że ma swoją wartość w niektórych kontekstach, ale w innych kontekstach przeszkadza.
Jednym z największych problemów, jakie znalazłem w OOP, jest to, że zmusza programistę do upieczenia struktury na długo, zanim programista faktycznie zrozumie, jaka powinna być ta struktura, co następnie prowadzi do delikatnego problemu z klasą podstawową .
Oczywiście dla wybranych aspektów WordPress, OOP ma wiele sensu i jeśli studiujesz rdzeń, znajdziesz takie klasy; Widget
, List_Tables
(w 3.1) itp.
W tym momencie cieszę się, że mogę pracować z WordPress w paradygmacie w większości innym niż OOP i myślę, że gdyby był to czysty OOP, WordPress nigdy nie uzyskałby takiej możliwości. Dlaczego? Ponieważ OOP podniosłoby poprzeczkę złożoności dla przyszłych twórców WordPressa i programistów wtyczek, i prawdopodobnie spowodowałoby to, że aplikacja nie była wystarczająco elastyczna, aby ewoluować, gdy główny zespół dowiedział się więcej o potrzebach swoich użytkowników w przeszłości 6 lat.
FWIW.
Wiele komponentów WP jest przepisywanych w kodzie OOP z każdą nową wersją, a nowe komponenty zwykle z niego korzystają (na przykład WP_Customizer
rzecz). Ale jeśli pytasz, czy WP zmieni architekturę w pełni obiektową - to nie, obecnie nie ma informacji sugerujących coś takiego.
Nie posunąłbym się tak daleko, by powiedzieć, że to się nigdy nie wydarzy, ale jest mało prawdopodobne, że tak się stanie w najbliższej przyszłości i prawdopodobnie nie z powodu problemu „klasy podstawowej” :)
Przede wszystkim korzystanie z kodu proceduralnego nad OOP dla aplikacji CMS, takich jak WordPress, ma tylko wady, ponieważ takie aplikacje mają być rozszerzone za pomocą wtyczek. Wrzucenie mieszanki funkcji i zmiennych globalnych wcale tego nie ułatwia. W momencie pisania WP nikt nie mógł przewidzieć, czym stanie się WP i dokonano wielu złych wyborów. Teraz jest to dość trudne do nadrobienia, ponieważ większość wtyczek i motywów przestałaby działać poprawnie. Wdrożenie ogromnej warstwy zgodności, aby tego uniknąć, prawdopodobnie spowolniłoby WP i spowodowałoby jeszcze większe zamieszanie wśród programistów. Pomyśl także o celu - aby ułatwić życie programistom, kosztem użytkowników?
Jeśli to pomaga - bardzo stara dyskusja na temat hakerów wp-h, ale wciąż aktualna w tym temacie, oraz propozycja społeczności, teraz oznaczona jako „terytorium wtyczki”. Ostatnio nie zauważyłem innej działalności w tym kierunku.