जवाबों:
मैं लगभग 99.9999% निश्चितता के साथ कह सकता हूं कि वर्डप्रेस भविष्य के संस्करण में कभी भी पूरी तरह से ओओपी नहीं बनेगा, जिनमें से कम से कम यह नहीं है कि विषय समय-समय पर फिर से आ गया है और फिर से डब्ल्यूपी-हैकर्स की सूची में और कोर टीम के सदस्यों ने इसमें कोई दिलचस्पी नहीं जताई है ऐसा करने से।
जैसा कि मैं 1990 के आसपास शुरू होने वाले प्रोग्रामिंग और शिक्षण ओओपी के साथ अपने व्यक्तिगत अनुभव को देखता हूं, मैं कोर टीम से सहमत हूं और लगता है कि पूर्ण ओओपी एक गलती होगी। हालांकि मैं एक बार एक OOP zealot था और सोचा था कि OOP एक रामबाण है क्योंकि मुझे विश्वास है कि कुछ संदर्भों में इसका मूल्य है, लेकिन अन्य संदर्भों में यह रास्ते में मिलता है।
OOP के साथ सबसे बड़ी समस्याओं में से एक यह है कि यह डेवलपर को संरचना में सेंध लगाने के लिए मजबूर करता है, इससे पहले कि डेवलपर वास्तव में यह समझे कि वह संरचना क्या होनी चाहिए जो तब नाजुक आधार-वर्ग समस्या की ओर ले जाती है ।
बेशक, वर्डप्रेस के चयनित पहलुओं के लिए, OOP बहुत मायने रखता है और यदि आप कोर का अध्ययन करते हैं तो आपको ऐसी कक्षाएं मिलेंगी; Widget, List_Tables (3.1 में) , आदि।
इस बिंदु पर मैं ज्यादातर गैर-ओओपी प्रतिमान में वर्डप्रेस के साथ काम करने में खुश हूं और सोचता हूं कि अगर यह शुद्ध ओओपी होता तो वर्डप्रेस कभी भी निम्न प्राप्त नहीं करता। क्यों? क्योंकि ओओपी ने वर्डप्रेस थ्रेसर और प्लगइन डेवलपर्स के लिए जटिलता की पट्टी उठाई होगी, और संभवत: यह एक ऐसे अनुप्रयोग के परिणामस्वरूप हुआ होगा जो कि विकसित करने के लिए पर्याप्त लचीला नहीं था क्योंकि कोर टीम अतीत में अपने उपयोगकर्ताओं की जरूरतों के बारे में अधिक जानती थी। 6 साल।
FWIW।
हर नए रिलीज के साथ बहुत सारे WP घटकों को OOP कोड में फिर से लिखा जाता है, और नए घटक इसका उपयोग करते हैं (उदाहरण के लिए WP_Customizerबात)। लेकिन अगर आप पूछ रहे हैं कि क्या WP अपने आर्किटेक्चर को पूरी तरह से ऑब्जेक्ट-ओरिएंटेड में बदल देगा - तो नहीं, वर्तमान में ऐसी कोई जानकारी नहीं है जो ऐसी बात का सुझाव दे।
मैं यह कहने के लिए इतनी दूर नहीं जाऊंगा कि यह कभी नहीं होगा, लेकिन निकट भविष्य में इसकी संभावना नहीं है, और शायद "बेस-क्लास" समस्या के कारण नहीं :)
सबसे पहले, वर्डप्रेस जैसे सीएमएस एप्लिकेशन के लिए ओओपी पर प्रक्रियात्मक कोड का उपयोग करने में केवल नुकसान हैं, सिर्फ इसलिए कि ऐसे ऐप को प्लगइन्स के माध्यम से बढ़ाया जाना है। फ़ंक्शंस और ग्लोबल वैरिएबल के मिश्रण में फेंकने से यह आसान नहीं होता है। जिस समय WP लिखा गया था उस समय कोई भी यह अनुमान नहीं लगा सकता था कि WP क्या होगा और कई खराब विकल्प बनाए गए थे। अब इसे पकड़ना काफी कठिन है, क्योंकि अधिकांश प्लगइन्स और थीम ठीक से काम करना बंद कर देंगे। एक बड़ी संगतता परत को लागू करने से बचने के लिए जो WP को धीमा कर देगा और डेवलपर्स के बीच और भी भ्रम को जोड़ देगा। उपयोगकर्ताओं के खर्च पर, डेवलपर्स के जीवन को आसान बनाने के उद्देश्य के बारे में भी सोचें?
यदि यह मदद करता है - wp-hackers पर एक बहुत पुरानी चर्चा, लेकिन अभी भी इस विषय के लिए प्रासंगिक है, और समुदाय द्वारा एक प्रस्तावित विचार , जिसे अब "प्लगइन क्षेत्र" के रूप में टैग किया गया है। मैंने हाल ही में इस दिशा में अन्य गतिविधि पर ध्यान नहीं दिया है।