become:स्मालटाक में संदेश, दूसरे में परिवर्तन करने के लिए एक वस्तु का कारण बनता है यह सभी संदर्भों को प्रभावित करने वाले।
इस भाषा की सुविधा का क्या उपयोग है? क्या यह वास्तविक कोड में उपयोग किया जाता है? क्या यह सिर्फ एक जिज्ञासा है? क्या इसका उपयोग करने के लिए एक अच्छा / बुरा अभ्यास माना जाता है?
जवाबों:
गिल्ड ब्राचाbecome: कुछ लंबाई के बारे में बात करते हैं :
स्मॉलटॉक की सबसे अनोखी और शक्तिशाली विशेषताओं में से एक यह भी है कि स्मॉलटॉक समुदाय के बाहर सबसे कम ज्ञात है। यह एक छोटी विधि बन गई है:
क्या बन जाता है: अपने रिसीवर की पहचान और उसके तर्क की अदला-बदली करता है। यही है, के बाद
a: बी
कॉल बिंदु से पहले निरूपित वस्तु के सभी संदर्भ, उस वस्तु का संदर्भ देते हैं, जिसे बी द्वारा निरूपित किया गया था, और इसके विपरीत।
इसे आंतरिक करने के लिए एक मिनट निकालें; आप इसे कुछ तुच्छ समझ सकते हैं। यह दो चरों की अदला-बदली के बारे में नहीं है - यह वस्तुतः एक वस्तु के दूसरे बनने के बारे में है। मुझे ऐसी किसी अन्य भाषा की जानकारी नहीं है जिसमें यह सुविधा है। यह विशाल शक्ति की एक विशेषता है - और खतरे।
लगातार वस्तुओं का समर्थन करने के लिए अपनी भाषा को विस्तारित करने के कार्य पर विचार करें। मान लें कि आप डिस्क से किसी ऑब्जेक्ट को लोड करना चाहते हैं, लेकिन यह सभी वस्तुओं को लोड नहीं करना चाहता है जो इसे संचरित करता है (अन्यथा, यह सिर्फ सादा ऑब्जेक्ट डीरिएलाइज़ेशन है)। इसलिए आप ऑब्जेक्ट को स्वयं लोड करते हैं, लेकिन इसके प्रत्यक्ष संदर्भों को लोड करने के बजाय, आप उन्हें भूसी वस्तुओं से बदल देते हैं।
द्वितीयक संग्रहण पर वास्तविक डेटा के लिए भूसी खड़ी है। उस डेटा को लोड किया गया है। जब आपको वास्तव में भूसी पर एक विधि को लागू करने की आवश्यकता होती है, तो इसका कोई मतलब नहीं है: विधि डिस्क से संबंधित डेटा ऑब्जेक्ट को लोड करती है (लेकिन फिर से, ट्रांसीवर नहीं)।
फिर, यह एक हो जाता है:, नए लोड किए गए ऑब्जेक्ट के संदर्भ में भूसी के सभी संदर्भों को प्रतिस्थापित करता है, और कॉल को फिर से करता है।
कुछ दृढ़ता इंजनों ने दशकों से इस तरह का काम किया है - लेकिन वे आमतौर पर प्रतिनिधित्व के निम्न स्तर तक पहुंच पर निर्भर थे। बनें: आपको स्रोत कोड स्तर पर ऐसा करने देता है।
अब इसे जावा में करें। या किसी अन्य गतिशील भाषा में भी। आप पहचानेंगे कि आप इस तरह से वायदा का एक सामान्य रूप कर सकते हैं, और इसलिए आलस्य। कार्यान्वयन के कामकाज के विशेषाधिकार के बिना सभी। यह स्कीमा के विकास के लिए भी उपयोगी है - जब आप किसी वर्ग के लिए एक उदाहरण चर जोड़ते हैं, उदाहरण के लिए। आप जरूरत के अनुसार सभी उदाहरणों को फिर से खोल सकते हैं।
बेशक, आपको उपयोग नहीं करना चाहिए: लापरवाही से। यह एक लागत पर आता है, जो कई कार्यान्वयनों में निषेधात्मक हो सकता है। शुरुआती स्मालटैक्स में, बन: सस्ता था, क्योंकि सभी वस्तुओं को एक वस्तु तालिका के माध्यम से परोक्ष रूप से संदर्भित किया गया था। ऑब्जेक्ट टेबल की अनुपस्थिति में, बनें: कूड़े को एक कलेक्टर के समान तरीके से हटाता है। आपके पास जितनी अधिक मेमोरी होती है, उतनी ही महंगी हो जाती है: बन जाती है।
ऑब्जेक्ट टेबल होने से स्टोरेज लेता है और पहुँच को धीमा करता है; लेकिन यह आपको लचीलेपन का एक बड़ा सौदा खरीदता है। हार्डवेयर समर्थन प्रदर्शन के दंड को कम कर सकता है। लाभ यह है कि यदि आप किसी वस्तु तालिका के माध्यम से अप्रत्यक्ष लागत का भुगतान करने को तैयार हैं तो कई कठिन समस्याएं काफी हद तक दूर हो जाती हैं। याद रखें: कंप्यूटर विज्ञान में हर समस्या को अप्रत्यक्ष के अतिरिक्त स्तरों के साथ हल किया जा सकता है। एलेक्स वॉर्थ में कुछ बहुत ही रोचक काम हैं जो इस श्रेणी में आते हैं, उदाहरण के लिए।
बनें: कई विविधताएँ हैं - एक तरीका बन जाता है: एक वस्तु A की पहचान को दूसरी वस्तु B से बदल देता है, ताकि A का संदर्भ B से मिलता है; B के संदर्भ अपरिवर्तित रहते हैं। यह अक्सर करना उपयोगी होता है: थोक में - सभी वस्तुओं की पहचान को एक सरणी में स्थानांतरित करना (या तो अप्रत्यक्ष या द्विदिश रूप से)। एक समूह बन जाता है: जो इसे जादुई रूप से जादू करता है, उदाहरण के लिए, सिस्टम में चिंतनशील अपडेट लागू करने के लिए बहुत अच्छा है। आप एक बार में कक्षाओं और उनके उदाहरणों के एक पूरे सेट को बदल सकते हैं।
तुम भी सुरक्षित प्रकार के गर्भ धारण कर सकते हैं:। दो तरह से बनते हैं: केवल एक प्रकार सुरक्षित है यदि A का प्रकार B के समान है, लेकिन एक तरीका बन जाता है: केवल यह आवश्यक है कि नई वस्तु पुराने के उप-प्रकार हो।
यह पुनर्विचार करने का समय हो सकता है कि क्या वस्तु तालिका वास्तव में एक अच्छी चीज है।
प्रभावी रूप से आपको जो मिलता है, वह एक प्रकार का आलसी लोडिंग होता है, जो कि मेटाप्रोग्रामिंग के लिए कितनी मात्रा में होता है। जैसा कि ब्राचा बताते हैं कि यह बहुत उपयोगी हो सकता है लेकिन यह खतरनाक भी है क्योंकि यह एक गंभीर प्रदर्शन प्रभाव ले सकता है।
Hardware support could ease the performance penalty.सभी जगहों पर मैंने यह सुना है, स्मॉलटॉक समुदाय सबसे प्रमुख रहा है। आदर्शवादी प्रोग्रामिंग प्रतिमानों को सक्षम करने पर हमें हार्डवेयर सुधारों को "खर्च" क्यों करना चाहिए, जब यह बढ़े हुए प्रदर्शन, बिजली के उपयोग में कमी या बढ़ी हुई क्षमता को जन्म दे सकता है।
इसका बहुत उपयोग नहीं किया जाता है। फ़ारो 5 की छवि जो मैंने खोली है, में # कैबोम के 9 प्रेषक हैं :, जिनमें से 7 यूनिट परीक्षणों में हैं। इसका उपयोग कोड पीढ़ी में कंपाइलर में और ईंधन क्रमांकन पुस्तकालय में उनकी सामग्री द्वारा परदे के पीछे बदलने के लिए किया जाता है।
becomeअपने कार्यक्रम के प्रदर्शन की तुलना में अपने विवेक पर प्रभाव के बारे में अधिक चिंतित हूँ ...