RubyConf 2010: रूबी (I) का वर्तमान और भविष्य

मेरा सुझाव है कि आप रूबी के लेखक की रिपोर्ट के दूसरे भाग का अनुवाद पढ़े, युकिहिरो मात्सुमोतो, रूबीकोनफ 2010 पर, उनके जापानी भाषा के ब्लॉग पर प्रकाशित हुआ। पहला भाग पिछले रूबी कॉन्फ सम्मेलनों का एक संक्षिप्त ऐतिहासिक अवलोकन है और प्रकाशन में कोई दिलचस्पी नहीं है।



जापानी से व्लादिमीर सदोवनिकोव में अनुवाद करने में मेरी मदद करने के लिए बहुत-बहुत धन्यवाद।

रूबी का भविष्य: रूबी 2.0

इस बार मैं रूबी में आने वाले कुछ नए फीचर पेश करूंगा:

• लक्षण ¹
• विधि संयोजन
• नामित तर्क
• नामस्थान

मुझे पूरा यकीन है कि अभी तक इस बारे में कोई बात नहीं हुई है। अंतर यह है कि:

• ये कार्य केवल विचार नहीं हैं जिन्हें एक दिन महसूस किया जा सकता है। इसलिए शुरुआत से ही करना जरूरी था।
• संबंधित कोड पहले से ही ट्रंक के लिए प्रतिबद्ध है।

¹ नोट प्रति।: गैर-तुच्छ तकनीकी शब्दों के लिए, मैं कोष्ठक में अंग्रेजी नाम और विकिपीडिया का लिंक दूंगा।

टाइप

प्रकार का निर्धारण:

प्रकार, "ऑब्जेक्ट-ओरिएंटेड प्रोग्राम्स को स्ट्रक्चर करने के लिए एक सरल वैचारिक मॉडल" के रूप में उपयोग की जाने वाली विधियों का एक संग्रह है।

विकिपीडिया से

यह लगभग मॉड्यूल के समान है। संक्षेप में, एक नया भाषा तत्व - प्रकार - मॉड्यूल की एक उप-प्रजाति है।



हालाँकि, मॉड्यूल की कार्यक्षमता को एक अलग तरीके से पेश करने के लिए, प्रकारों को शामिल करने के अलावा एक विधि का उपयोग करके मिश्रणों को लागू करते हैं [अन्य मॉड्यूल - इसके बाद वर्ग कोष्ठक में लगभग। ट्रांस।]। चूंकि यह विधि अधिक लचीली है, इसलिए मॉड्यूल को सक्षम करने की क्षमता को पूरी तरह से हटा दिया गया है।



समावेश के साथ समस्याएं हैं:

• नाम संघर्ष का पता नहीं चला है।
• यदि उनके क्रम में परिवर्तन होता है, तो खराबी शुरू हो जाती है।
• किसी अन्य मॉड्यूल के साथ एक विधि लपेटने के बाद, आप मूल विधि तक नहीं पहुँच सकते।

जब समावेश को कई वंशानुक्रम का अनुकरण करने के लिए उपयोग किया जाता है, तो स्थितियों का अनुमान लगाने में कुछ मुश्किल पैदा होती है।



उनमें से एक यह है कि एक मॉड्यूल शामिल करने की एक विधि जिसमें पहले से ही वर्तमान संदर्भ में परिभाषित किया गया है, में पूरी तरह से अलग लक्ष्य और परिणाम हो सकते हैं: [जानबूझकर] पहले से परिभाषित विधि, आकस्मिक संयोग (नाम संघर्ष), या दोनों वास्तव में आवश्यक हैं। विधि, और उनके नाम अद्वितीय होने चाहिए।



एक और समस्या यह है कि मॉड्यूल के उत्तराधिकार का क्रम और, तदनुसार, मिलान नामों के साथ तरीकों की खोज का क्रम अक्सर प्रतिरूपक हो सकता है।

module American attr_accessor :address end module Japanese attr_accessor :address end class JapaneseAmerican include American include Japanese end JapaneseAmerican.new.address # which address? p JapaneseAmerican.ancestors # => [JapaneseAmerican, Japanese, American, Object, Kernel]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस उदाहरण में, पता विशेषता विधि अमेरिकी और जापानी दोनों मॉड्यूल में निहित है, डेवलपर के अनुरोध पर अतिव्यापी या गलती से भाषा के ज्ञान की कमी के कारण। परिणामस्वरूप, इनहेरिटेंस के आदेश के अनुरूप तरीकों को केवल एक क्रम में बुलाया जाएगा।



एक "अच्छी तरह से प्रशिक्षित" रूबिस्ट प्रोग्रामर, इस कोड को देखकर, निश्चित रूप से समझ जाएगा कि जापानी मॉड्यूल से पता विधि कहा जाएगा।



रूबी [MRI 1.9] वर्तमान में प्रतिमान का उपयोग कर रहा है "एक मॉड्यूल को दो बार विरासत में नहीं लिया जाना चाहिए, भले ही मूल वर्ग में पहले से ही यह मॉड्यूल शामिल हो" (लेखक नोट: ऐसा लगता है कि MacRuby ने ऐसा ही किया था। 1.9 में इसे बदलने का प्रयास किया गया था, लेकिन के लिए। YARV के लिए आवश्यक है कि मॉड्यूल पूर्वजों के बीच दो बार दिखाई न दे।) इसलिए यदि आप एक ऐसे वर्ग में एक मॉड्यूल शामिल करते हैं, जिसकी मूल कक्षा में पहले से ही यह मॉड्यूल शामिल है, तो यह उन पूर्वजों के बीच प्रकट नहीं होगा जहां आप इसकी अपेक्षा करते हैं।



इसके अलावा, चूंकि मॉड्यूल को शामिल करना वर्तमान वर्ग के पूर्वजों को इस मॉड्यूल में शामिल सभी मॉड्यूल के रूप में अच्छी तरह से जोड़ता है, और उसके बाद वे अब इस वर्ग के लिए विशिष्ट स्थान में शामिल नहीं हो सकते हैं। अंत में, मॉड्यूल सहित वंशानुक्रम को और अधिक भ्रमित करता है।



इन समस्याओं (भाग में) को मिक्स विधि द्वारा हल किया जाता है।



क्यों मिलाते हैं? क्योंकि:

• क्लास के तरीकों को वर्तमान मॉड्यूल / प्लग-इन मॉड्यूल में परिभाषित किया गया है।
• जब आप मॉड्यूल चालू करते हैं तो पूर्वज नहीं बनते।
• मिलान विधि नाम एक अपवाद फेंकता है।
• यदि आपको अभी भी मिलान विधियों के नाम के साथ एक मॉड्यूल शामिल करना है, तो आप उनका नाम बदल सकते हैं।
• लगातार चालू या बंद किया जा सकता है (डिफ़ॉल्ट रूप से वे शामिल नहीं हैं)।

इस प्रकार, मिश्रण को निम्नानुसार लागू किया जाता है:

• विधि के डुप्लिकेट को जोड़ने की कोशिश करने से त्रुटि होगी, क्योंकि संघर्ष को स्वचालित रूप से हल नहीं किया जा सकता है।
• इसे स्पष्ट रूप से निर्दिष्ट करके विधि के नाम बदले जा सकते हैं।
• मॉड्यूल अभी भी एक अजीब तरीके से वंशानुक्रम श्रृंखला में शामिल हैं। (इस समस्या का समाधान नहीं किया गया है, सौभाग्य। * मुस्कराहट *)

उदाहरण के लिए, इस कोड में एक ही नाम के तरीके हैं, और इसलिए मिश्रण काम नहीं करेगा:

 module American attr_accessor :address end module Japanese attr_accessor :address end class JapaneseAmerican mix American mix Japanese # => address conflict! end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मिश्रण को काम करने के लिए, आपको स्पष्ट रूप से नाम संघर्षों को हल करना होगा:

 class JapaneseAmerican mix American, :address => :us_address mix Japanese, :address => :jp_address end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अब विधियाँ, जिन्हें एक ही कहा जाता था, अलग-अलग नामों से मिलीं।



आप पूछ सकते हैं, क्यों, भाषा को जटिल बनाने के बजाय, शामिल करने के मापदंडों को शामिल करने की क्षमता को शामिल करने की विधि शामिल करें? क्योंकि विधि का छोटा नाम का अर्थ है कि यह उपयोग करने के लिए बेहतर है। (नोट perev।: इस कारण से सभी आत्मनिरीक्षण विधियां जो संभावित रूप से कोड को समझना मुश्किल बना सकती हैं, जैसे "example_variable_defined?") के विस्तृत नाम हैं।



नाकाडा [संभवत: रूबी कर्नेल के डेवलपर्स में से एक नकुयुशी नाकाडा] ने रूबीकिगी [जापानी रूबी सम्मेलन] में इस समारोह की घोषणा के समय मिश्रण विधि को लागू करने के लिए आवश्यक लक्षण विकसित करना शुरू कर दिया है, इसलिए पैच तैयार है।



हालाँकि, विभिन्न प्रस्तुतियाँ निम्नलिखित मुद्दों को संबोधित नहीं करती हैं, जिसके लिए अभी भी निर्णय लेना आवश्यक होगा:

• [इस जगह पर दो बिंदु थे जिनका मैं अनुवाद नहीं कर सकता था। खेद है।]
• किसी वर्ग के सदस्य चर के बीच संघर्ष को हल करने के लिए कोई उपाय नहीं हैं। चूंकि बच्चे की कक्षाओं के सदस्य चर माता-पिता के लिए अदृश्य रूप से जोड़े जाते हैं, इसलिए जब मॉड्यूल के साथ मिश्रण करने वाले वर्ग को लागू करते हैं, तो आपको सदस्य चर के लिए अवांछित नामों पर विचार करना होगा और उनसे बचना होगा। 1.9 के लिए एक पैच है, जो फॉर्म के सदस्य चर को @_foo या @__foo निजी बनाता है, लेकिन वर्तमान स्थिति में यह समझना मुश्किल है कि इसे कैसे लागू किया जाना चाहिए या, शायद, यह सामान्य रूप से इस तरह के फ़ंक्शन को छोड़ने के लायक है। मिश्रण की शुरुआत के बाद इस समस्या पर अधिक ध्यान देना होगा।

विधि संयोजन

RubyKaigi में, मिश्रण विधि संयोजन के बारे में कहानी का हिस्सा था, लेकिन फिर यह पता चला कि कहानी के कुछ हिस्सों में "रैप" करने की क्षमता से संबंधित एक विधि अन्य विधियों को कॉल करने के लिए सबसे गैर-तुच्छ थी, और इसे अलग से हाइलाइट किया।



सुझाव है कि प्रीपेंड पद्धति शुरू की जाए। मैं पहले से ही सवाल सुनता हूं "हम पहले से ही शामिल हैं और मिश्रण करते हैं, क्या, अब हमें एक और विधि की आवश्यकता है?", और मुझे विश्वास है कि यह वास्तव में आवश्यक है।



यह विधि आपको किसी भी फ़ंक्शन को जोड़ने के लिए "क्लास" से पहले एक और विधि जोड़ने की अनुमति देती है।

 module Foo def foo p :before super p :after end end class Bar def foo p :foo end prepend Foo end Bar.new.foo # :before, :foo, :after
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अगर फू विधि को फू मॉड्यूल में परिभाषित किया गया है, और इसे वर्तमान वर्ग (या मॉड्यूल) में भी परिभाषित किया गया है, तो प्रीपेंड मॉड्यूल फू विधि का उपयोग करके कॉल को वर्तमान वर्ग के फू विधि में लपेट देगा।



प्रीपेंड पद्धति का विचार येहुदा काट्ज़ से आता है, जो एक रेल डेवलपर भी है; वह सोचता है कि रेल में alias_method_chain के साथ उसे प्रतिस्थापित करना बहुत अच्छा होगा, और मैं उससे सहमत हूं।



इस संभावना का कोई ठोस कार्यान्वयन अभी तक नहीं हुआ है, हालांकि विरासत की श्रृंखला में T_ICLASS ऑब्जेक्ट को जोड़ना सबसे आसान है। इससे इसे शुरू करना काफी संभव है।

नामित तर्क

लोग तर्कों और विशेष रूप से वैकल्पिक लोगों के उद्देश्य को भूल जाते हैं। उदाहरण के लिए, public_instance_methods विधि एक वैकल्पिक तर्क लेती है, जिसका अर्थ है "यदि गलत पारित हो गया है, तो मूल वर्ग के तरीके भी वापस करें," या इसके विपरीत, मैं हमेशा यह भूल जाता हूं। (वास्तव में, सच है।)



उदाहरण के लिए

 aClass.public_instance_methods (include_super: false)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह याद रखना बहुत आसान है।



रूबी 1.9 में, नामित तर्क डिफ़ॉल्ट के रूप में एक हैश के साथ अंतिम तर्क हैं, और व्याकरण विस्तार जो इस एचएच को आरंभ करता है। (नोट अनुवाद: कुछ लोगों को पता है कि 1.9 में आप डी def a(opts={}); end



तरह एक विधि बना सकते हैं def a(opts={}); end



और इसे a(go: true, what: "string")



जैसे a(go: true, what: "string")



।



नई सुविधा 2.0 एक विधि को परिभाषित करते समय ऐसी प्रविष्टि को निर्दिष्ट करने का एक आसान तरीका है। उदाहरण के लिए:



कॉल करें:

 1.step (by: 2, to: 20) do |i| pi end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

विधि कहा जाता है:

 def step (by: step, to: limit) ... end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

बाद में [समुदाय] हैश रूप लेता है, नाम के तर्कों को जोड़ना होगा, प्रभाव में, एक छोटा सा परिवर्तन।

नामस्थान

यदि आप तकनीकी विवरणों में रुचि रखते हैं, तो शुगो मादे की प्रस्तुति पर एक नज़र डालें, जो रूबॉन्फ़ पर भी था।



रूबी में कक्षाएं सार्वजनिक हैं। इसका मतलब है कि किसी भी समय आप किसी मौजूदा वर्ग में एक विधि जोड़ सकते हैं। इस वर्ग परिवर्तन तकनीक को मंकी पैचिंग कहा जाता है।



यह मुझे लगता है कि यह शब्द "गुरिल्ला पैचिंग" [छापामार - छापामार] -> "पैचिंग गोरिल्ला" -> "बंदर पैचिंग" द्वारा उत्पन्न किया गया था। बेशक, अगर रूबी जैसी भाषा में, कक्षाएं बदलना आसान है, तो मुझे यकीन है कि यह अवसर प्रदान किया जाना चाहिए। यही कारण है कि डीएचएच की रिपोर्ट [डेविड हेनीमियर हैनसन, रेल्स के लेखक], "बंदर के भविष्य के बिना," मैं "परिवर्तन की स्वतंत्रता के बिना एक भविष्य" कहता हूं। [यहाँ मेल गिब्सन का एक उद्धरण था, लेकिन मेरे मस्तिष्क के पार्सर ने इसे मास्टर नहीं किया]।



एक ओर, स्वतंत्रता अच्छी है, लेकिन दूसरी ओर, यह बहुत अधिक प्रभाव डाल सकता है। बेशक, आप पूर्णांकों के लिए जोड़ को फिर से परिभाषित कर सकते हैं ताकि 1 + 2 42 हो, लेकिन अधिकांश प्रोग्राम साइड इफेक्ट्स के कारण काम करना बंद कर देंगे।



समस्या यह है कि इस तरह के सभी परिवर्तन पूरे कार्यक्रम में विश्व स्तर पर लागू होते हैं। एक बंद दायरे में परिवर्तन रखकर, आप "मुक्त परिवर्तन" [पैचिंग की स्वतंत्रता] का एक सुविधाजनक और सुरक्षित तरीका प्राप्त कर सकते हैं।



ऐसा "स्कोप" पहले से प्रस्तावित चयनकर्ता नेमस्पेस क्लासबॉक्स हो सकता है; इस बार, Maeda के सहकर्मी द्वारा कार्यान्वित चयनकर्ता नामस्थान को परिशोधन कहा जा सकता है।



उदाहरण के लिए, इस तरह एक कार्यक्रम है:

 class Integer def / (other) return quo (other) end end p 1 / 2 # => (1 / 2)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

डिवीजन ऑपरेटर (/) का एक समान पुनर्निर्धारण एक तर्कसंगत अंश के रूप में परिणाम को वापस करने के लिए (नोट: इस मामले में, तर्कसंगत वर्ग की एक वस्तु वापस आ गई है) मानक मैथन लाइब्रेरी का हिस्सा है। हालाँकि, कोड जो पूर्णांक विभाजन की अपेक्षा करता है, एक पूर्णांक के परिणामस्वरूप भी इस तरह के बदलाव के कारण काम करना बंद कर सकता है।



यह अध्ययन एक परिशोधन प्रस्तावित करता है (नाम बदल सकता है)। व्याकरण इस तरह दिख सकता है:

 module MathN refine Integer do def / (other) return quo (other) end end p 1 / 2 # => (1 / 2) end p 1 / 2 # => 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मॉड्यूल के हिस्से के रूप में शोधन का उपयोग किया जाता है। मॉड्यूल। यह एक बड़ी उपलब्धि है।



मॉड्यूल के अंदर, आप मौजूदा कक्षाओं को परिष्कृत कर सकते हैं, और ऐसे परिवर्तन केवल नाम स्थान के भीतर दिखाई देंगे। इस प्रकार, मॉड्यूल के अंदर, MathN 1/2 तर्कसंगत (1/2), और मॉड्यूल के बाहर - सामान्य भागफल लौटाएगा।



क्लासबॉक्स शोधन से अंतर यह है कि यद्यपि शाब्दिक गुंजाइश पहले ही समाप्त हो चुकी है, फिर भी शोधन प्रभावी है; इसी कारण से, कई प्रोग्रामिंग लैंग्वेज डायनेमिक स्कोप का उपयोग करती हैं। बेशक, शोधन को अनिवार्य रूप से काम करना चाहिए, न कि शाब्दिक रूप से।



एक नाम स्थान उपयोग करने की विधि का उपयोग करने वाला एक मॉड्यूल है:

 module Rationalize using MathN p 1 / 2 # => (1 / 2) end p 1 / 2 # => 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

युक्तिसंगत मॉड्यूल में भी मैथन में परिभाषित शोधन है।



इसके अतिरिक्त, यदि कोई विधि वर्ग विधि के रूप में परिभाषित करने के लिए निरर्थक है, तो इसे दूसरी विधि के अंदर परिभाषित किया जा सकता है। विधि के भीतर, यह स्पष्टीकरण के रूप में उसी तरह काम करेगा: इस तरह से, विधि को पूरी तरह से निजी बनाया जा सकता है। (नोट perev।: रूबी 1.9 में, इस तरह से परिभाषित एक विधि वर्ग की सदस्य विधि बन जाती है, अर्थात, घोंसला बनाना कोई मायने नहीं रखता है।)

 class Foo def foo def bar ... end bar # works end def quux bar # does not work end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह परिवर्तन Maeda पर काम कर रहा है काफी बड़ा और जटिल है; हालाँकि, परिवर्तन जल्दी से मुख्य पेड़ [ट्रंक] में एकीकृत हो जाते हैं, लेकिन अब, आप इस शानदार पैच के लिए माएडा के एक सहयोगी की सराहना कर सकते हैं।



PS यह अनुवाद सरल से बहुत दूर था, और मुझे पता है कि कई वाक्यांश किसी भी क्रिप्टोकरंसी को पागल कर देंगे, लेकिन मेरे विवेक ने मुझे केवल उन मनमाने भागों को पाठ से निकालने की अनुमति नहीं दी जो अनुवाद करने में आसान थे। मुझे उम्मीद है कि अधिकांश दिलचस्प चीजें कुछ जीवित टिप्पणियों और स्रोत कोड से स्पष्ट होंगी। और मैं वादा करता हूं कि अगले भाग का अनुवाद अधिक स्पष्ट होगा।