Yanıtlar:
WordPress'in gelecek sürümde hiçbir zaman tamamen OOP olmayacağını kesin olarak söyleyebilirim, en azından konunun wp-hackerlar listesinde tekrar tekrar ortaya çıktığı ve çekirdek ekip üyelerinin ilgi göstermediği değil Bu şekilde.
1990 yılından itibaren OOP'yi programlama ve öğretme konusundaki kişisel deneyimime baktığımda çekirdek takıma katılıyorum ve OOP'un tamamının bir hata olacağını düşünüyorum. Her ne kadar bir zamanlar bir OOP zealot ve OOP'un her derde deva olduğunu düşündüm, ancak o zamandan beri bazı bağlamlarda değerine sahip olduğuna inanıyorum, ancak diğer bağlamlarda yol alıyor.
OOP ile bulduğum en büyük sorunlardan biri, geliştiricinin aslında bu yapının ne olması gerektiğini anlamadan çok önce yapıyı pişirmeye zorlamasıdır ve bu da kırılgan taban sınıfı sorununa yol açar .
Tabii ki WordPress'in seçilmiş yönleri için, OOP çok mantıklı ve eğer çekirdek dersi alırsanız bu sınıfları bulacaksınız; Widget, List_Tables (3.1'de) vb.
Bu noktada, çoğunlukla OOP olmayan bir paradigmada WordPress ile çalışmaktan ve saf olsaydı OOP WordPress'in aşağıdakileri asla kazanamayacağını düşünüyorum. Neden? Çünkü OOP, WordPress temaları ve eklenti geliştiricileri için karmaşıklık çıtasını yükseltecekti ve çekirdek ekip, geçmişte kullanıcılarının ihtiyaçları hakkında daha fazla bilgi edinirken gelişecek kadar esnek olmayan bir uygulama ile sonuçlanacaktı. 6 yıl.
FWIW.
Birçok WP bileşeni, her yeni sürümle OOP kodunda yeniden yazılır ve yeni bileşenler, onu (örneğin, WP_Customizerşey) kullanma eğilimindedir . Ancak WP'nin mimarisini tamamen nesne yönelimli bir mimariye dönüştürüp değiştirmeyeceğini soruyorsanız - o zaman hayır, şu anda böyle bir şey öneren hiçbir bilgi yoktur.
Ben asla olmayacağını söylemek için şimdiye kadar gitmek olmaz, ama muhtemelen yakın gelecekte olacak ve muhtemelen "temel sınıf" sorunu nedeniyle değil :)
Her şeyden önce, WordPress gibi bir CMS uygulaması için OOP üzerinden prosedürel kod kullanmanın sadece dezavantajları vardır, çünkü bu tür uygulamalar eklentiler yoluyla genişletilmelidir. Fonksiyonlar ve küresel değişkenlerin bir karışımına atmak bunu hiç de kolaylaştırmaz. WP yazıldığı sırada kimse WP'nin ne olacağını tahmin edemezdi ve birçok kötü seçim yapıldı. Çoğu eklenti ve tema düzgün çalışmayı bırakacağı için artık yakalamak oldukça zor. Bunu önlemek için büyük bir uyumluluk katmanı uygulamak muhtemelen WP'yi yavaşlatacak ve geliştiriciler arasında daha fazla karışıklık yaratacaktır. Ayrıca amaç düşünün - kullanıcıların pahasına geliştiricilerin hayatını kolaylaştırmak için?
Eğer yardımcı oluyorsa - wp-hackerlar hakkında çok eski bir tartışma ama yine de bu konuyla ilgili ve topluluk tarafından önerilen bir fikir , şimdi "eklenti bölgesi" olarak etiketlendi. Son zamanlarda bu yönde başka bir etkinlik fark etmedim.