स्मॉलटाकल में मेटाक्लासेस

यह लेख, मुझे आशा है, न केवल उन लोगों के लिए उपयोगी होगा जो स्मालटाक सीखना चाहते हैं, बल्कि उन लोगों के लिए भी हैं जो ऑब्जेक्ट सिस्टम के निर्माण की समस्याओं को बेहतर ढंग से समझना चाहते हैं। स्मालटाक में, कक्षाएं पूर्ण वस्तुएं हैं, और इसे कैसे लागू किया जाता है यह बिना किसी जटिलता के कई सरल सिद्धांतों के आधार पर एक विकसित प्रणाली के निर्माण का एक उत्कृष्ट उदाहरण है।

(हालांकि, मैं उद्देश्य-सी में हाल ही में प्रकाशित लेख मेटाक्लासेस के साथ संबंध से इनकार नहीं करूंगा।)

मेटाक्लस की अवधारणा को समझने के लिए, हमें केवल दो सिद्धांतों की आवश्यकता है, जिसमें से हम (लगभग स्पष्ट) तार्किक निष्कर्ष निकालेंगे।

पहला सिद्धांत सामान्य रूप से ऑब्जेक्ट प्रोग्रामिंग के लिए मौलिक है और, सिद्धांत रूप में, किसी भी वस्तु भाषा के लिए ऐसा होना चाहिए (किसी भी मामले में स्मॉलटाक के लिए, यह ऐसा है):

सब कुछ एक वस्तु है, अर्थात्, यह संदेश प्राप्त कर सकता है और उन्हें जवाब दे सकता है।

कक्षाएं भी इसी "सब कुछ" के अंतर्गत आती हैं। उदाहरण के लिए, हम उन वस्तुओं को कक्षा में संदेश भेजते हैं, जिनका उदाहरण हम बनाना चाहते हैं:

point := Point x: 1 y: 2. 

चमत्कारिक ढंग से वस्तुओं को बनाने के लिए कोई अलौकिक विशेष अभियान, सिर्फ संदेश भेजना। इस मामले में, हम दो निर्देशांक में एक बिंदु प्राप्त करने की आशा में संदेश #x:y: Point वर्ग में भेजते हैं।

दूसरा सिद्धांत ऑब्जेक्ट प्रोग्रामिंग के लिए मौलिक नहीं है, लेकिन स्मॉलटॉक में (अधिकांश आधुनिक वस्तु भाषाओं में), दुर्भाग्य से, इसे नहीं रखा गया था:

किसी वस्तु का व्यवहार उसकी कक्षा द्वारा निर्धारित किया जाता है: कक्षा में विधियों का एक सेट वर्णित होता है जो किसी विशेष संदेश के उदाहरणों की प्रतिक्रिया का वर्णन करता है।

तो, Point वर्ग के लिए बिंदुओं के सभी तरीकों को परिभाषित किया गया है - यह समझ में आता है। हम उस वस्तु के वर्ग का पता #class उसे संदेश भेज सकते हैं #class ।

 point class."-> Point" 

लेकिन जहां #x:y: विधि को #x:y: , जो Point क्लास द्वारा उसी संदेश के प्रसंस्करण का वर्णन करता है?

कुछ नई संस्थाओं या नियमों को लागू करके प्रणाली को जटिल नहीं करने के लिए, आप मौजूदा एक का उपयोग कर सकते हैं: #x:y: विधि #x:y: को उस वर्ग में परिभाषित किया जाना चाहिए जिसका उदाहरण Point वर्ग है। "क्लास ऑफ़ क्लास" के निर्माण को "मेटाक्लास" शब्द से बदल दिया जाता है। निश्चित रूप से, Point #class को Point क्लास में #class संदेश भेजकर प्राप्त किया जा सकता है:

 point class class."-> Point class" Point class."-> Point class" 

जैसा कि आप देख सकते हैं, मेटाक्लास Point सिस्टम में अपना नाम नहीं सौंपा गया है। मेटाक्लास को स्मॉलटॉक अभिव्यक्तियों द्वारा निरूपित किया जाता है जिसके द्वारा उन्हें प्राप्त किया जा सकता है।

इस तथ्य से यह भी पता चलता है कि प्रत्येक वर्ग की अपनी मेटाक्लास है । हमें निश्चित रूप से प्रति वर्ग एक से अधिक मेटाक्लास की आवश्यकता नहीं है, लेकिन प्रत्येक वर्ग के लिए एक भी थोड़ा अधिक है। आपको इतनी आवश्यकता क्यों है?

स्मॉलटाक -76 में, सभी वर्गों के लिए केवल एक मेटाक्लस था। लेकिन अगर कई वर्गों के पास उनकी मेटाक्लस के समान वस्तु है, तो उनके पास एक ही व्यवहार है, क्योंकि यह मेटाक्लस में बिल्कुल परिभाषित है। उदाहरण के लिए, संदेश #x:y: इस मामले में किसी भी वर्ग को भेजा जा सकता है: String , Integer , आदि। जाहिर है, यह बहुत अच्छा नहीं है। एक विकल्प वर्ग के पक्ष में कस्टम व्यवहार की पूरी अनुपस्थिति है (जो कि कोई बेहतर नहीं है), या (इससे भी बदतर) प्रोग्रामर को भाषा के स्तर पर अन्यतम रूप से काले जादू पर निर्भर बनाते हैं - जैसा कि अधिकांश "आधुनिक" मुख्यधारा की रचनाओं में है।

इसलिए, सिस्टम में प्रत्येक वर्ग के लिए, हमें एक और ठीक एक मेटाक्लस की आवश्यकता होती है जो इस वर्ग के व्यवहार को परिभाषित करता है। स्मॉलटाकल में, एक मेटाक्लास स्वचालित रूप से "ऑफ-स्क्रीन" बनाया जाता है जब एक नया वर्ग बनाया जाता है।

यह देखते हुए कि मेटाक्लासेस (पहला सिद्धांत देखें) ऑब्जेक्ट हैं और (दूसरा सिद्धांत देखें) एक निश्चित वर्ग के उदाहरण हैं, हम यह निष्कर्ष निकालते हैं कि उपर्युक्त मेटाक्लासेस पर स्वयं लागू होता है। लेकिन एक ख़ासियत है: "साधारण" वर्गों के विपरीत, मेटाक्लासेस को विशिष्ट व्यवहार की आवश्यकता नहीं है - वे सभी अपने उदाहरणों के व्यवहार को उसी तरह से संग्रहीत करते हैं, कुछ भी अधिक आवश्यक नहीं है। इसलिए, प्रत्येक मेटाक्लस के लिए एक अलग (मेटा-) मेटाक्लास होना आवश्यक नहीं है; सिस्टम में सभी मेटाक्लासेस के व्यवहार को निर्धारित करने के लिए सिर्फ एक वस्तु पर्याप्त है। उन्हें Metaclass कहा जाता था:

 Point class class."-> Metaclass" 

उसी सिद्धांतों के आधार पर, और उसी तर्क को लागू करते हुए, हम यह निष्कर्ष निकालते हैं कि Metaclass में एक मेटाक्लस भी होना चाहिए:

 Metaclass class."-> Metaclass class" 

कृपया ध्यान दें कि मेटाक्लास मेटाक्लास (अनावश्यक के रूप में) को अपना नाम नहीं दिया गया था।

और एक बार फिर हम दोहराते हैं Metaclass : मेटाक्लास मेटाक्लास (जैसे सभी मेटाक्लासेस) Metaclass :

 Metaclass class class."-> Metaclass" 

श्रृंखला बंद है, यही हमें मिला है:


हमने उत्तराधिकार के मुद्दे को संबोधित नहीं किया, लेकिन सब कुछ सरल है: चूंकि कक्षाओं का व्यवहार वस्तुओं के व्यवहार के समान विरासत में मिला है, इसलिए मेटाक्लास सी का सुपरक्लास सुपरक्लास सी का मेटाक्लस है:

 Point superclass."-> Object" Point class superclass."-> Object class" Object superclass."-> ProtoObject" Object superclass class."-> ProtoObject class" 

इस नियम (बाध्य) का उल्लंघन केवल उसी स्थान पर किया जाता है जहां वंशानुक्रम श्रृंखला टूटती है: प्रोटोऑब्जेक्ट में एक सुपरक्लास नहीं होता है, लेकिन इसका मेटाक्लास एक वर्ग होना चाहिए:

 ProtoObject superclass."-> nil" ProtoObject class superclass."-> Class" 

निष्कर्ष में - छोटी टिप्पणी की एक जोड़ी जो प्रासंगिक नहीं है, लेकिन दिलचस्प है।
मेटाक्लास पूर्ण वर्ग नहीं हैं, क्योंकि पूर्व को बाद की सभी कार्यक्षमता की आवश्यकता नहीं है:

 Metaclass superclass."-> ClassDescription" 

और उन लोगों के लिए जो तस्वीर को पूरी तरह से खत्म करना चाहते हैं, लेकिन स्मालटाक चलाना नहीं चाहते हैं:

 Class superclass."-> ClassDescription" ClassDescription superclass."-> Behavior" Behavior superclass."-> Object"