Відповіді:
Я можу сказати з упевненістю приблизно на 99,9999%, що WordPress ніколи не стане повністю OOP у майбутній версії, не останнє з яких полягає в тому, що тема знову і знову з’являється у списку хакерів-wp, і члени основної команди не виявляють інтересу до роблячи так.
Коли я дивлюся на свій особистий досвід програмування та викладання OOP, починаючи з 1990 року, я погоджуюся з основною командою і думаю, що повний OOP був би помилкою. Хоча я колись був завзятим OOP і вважав, що OOP - панацея, я з тих пір вважаю, що він має свою цінність в деяких контекстах, але в інших контекстах це стає у дорозі.
Однією з найбільших проблем, з якою я стикався з OOP, є те, що він змушує розробника запікатися в структурі задовго до того, як розробник насправді зрозуміє, якою повинна бути ця структура, що потім призводить до крихкої проблеми базового класу .
Звичайно, для вибраних аспектів WordPress, OOP має багато сенсу, і якщо ви вивчите основні, ви знайдете такі класи; Widget, List_Tables (в 3.1) тощо.
На даний момент я радий працювати з WordPress в основному не парадигмі OOP, і думаю, що якби це була чисто OOP, WordPress ніколи не отримав би наступного. Чому? Оскільки OOP підніме планку складності для потенційних темер WordPress та розробників плагінів, і це, швидше за все, призвело б до появи не достатньо гнучкої програми для розвитку, оскільки основна команда дізналася більше про потреби своїх користувачів за останній час 6 років.
FWIW.
Багато компонентів WP переписуються в код OOP з кожним новим випуском, і нові компоненти, як правило, використовують його (наприклад, WP_Customizerріч). Але якщо ви запитуєте, чи WP змінить свою архітектуру на цілком об'єктно-орієнтовану - тоді ні, наразі немає інформації, яка б напрошувала таке.
Я б не пішов так далеко, щоб сказати, що це ніколи не відбудеться, але навряд чи це буде найближчим часом, і, мабуть, не через проблему "базового класу" :)
Перш за все, є лише недоліки у використанні процедурного коду через OOP для такої програми CMS, як WordPress, просто тому, що такі додатки мають розширюватися за допомогою плагінів. Додавання суміші функцій та глобальних змінних зовсім не полегшує це. На момент написання програми WP ніхто не міг передбачити, яким стане WP, і було зроблено багато поганих виборів. Зараз це досить важко наздогнати, бо більшість плагінів і тем перестануть працювати належним чином. Реалізація величезного рівня сумісності, щоб уникнути, що, ймовірно, сповільнить WP та додасть ще більше плутанини серед розробників. Також подумайте про мету - полегшити життя розробникам за рахунок користувачів?
Якщо це допомагає - дуже стара дискусія про wp-хакерів, але все ще актуальна для цієї теми, і запропонована громадою ідея , тепер позначена як "територія плагінів". Останнім часом я не помічав іншої активності в цьому напрямку.