2015-02-12 6 views
5

हम कीवर्ड तर्क को स्ट्रिंग कुंजी के साथ हैश के रूप में पास नहीं कर सकते हैं, कीवर्ड तर्क केवल हैश के साथ प्रतीक कुंजी के रूप में काम करता है।कीवर्ड तर्कों को प्रतीक कुंजी के साथ हैश के रूप में क्यों पारित किया जाना चाहिए, रूबी में स्ट्रिंग कुंजियां नहीं?

एक साधारण उदाहरण:

def my_method(first_name:, last_name:) 
    puts "first_name: #{first_name} | last_name: #{last_name}" 
end 

my_method({last_name: 'Sehrawat', first_name: 'Manoj'}) 
#=> first_name: Manoj | last_name: Sehrawat 

my_method({first_name: 'Bob', last_name: 'Marley'}) 
#=> first_name: Bob | last_name: Marley 

my_method({'first_name' => 'Kumar', 'last_name' => 'Manoj'}) 
#=> Error: missing keywords: first_name, last_name (ArgumentError) 

उसके पीछे के तर्कों क्या है?

+0

मुझे लगता है कि विचार के समान है http://stackoverflow.com/questions/8189416/why- उपयोग-प्रतीकों के रूप में-हैश-चाबियाँ-इन-रूबी – freemanoid

+0

@ फ़्रेमेनोइड मुझे ऐसा नहीं लगता है। इस मामले में, वाक्यविन्यास एक स्थानीय चर को स्वीकार करने के बारे में है। इसमें कोई प्रतीक शामिल नहीं है। – sawa

उत्तर

1

हालांकि कीवर्ड तर्क एक हैश के भीतर पारित किया जा सकता, मुझे लगता है कि मुख्य रूप से लक्षित उपयोग सीधे key: value सिंटैक्स का उपयोग करने के लिए है:

my_method(first_name: 'Bob', last_name: 'Marley') 

जहां तक ​​इस फार्म का संबंध है, वहाँ कोई प्रतीक कुंजी है (या सरणी कुंजी) यहाँ। key: value सिंटैक्स सीधे कीवर्ड तर्कों को इंगित करना है।

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

+0

यह गलत हो सकता है। क्षमा करें अगर यह है। – sawa

+1

'प्रतीक: कुंजी 'वाक्यविन्यास 1.9 में वास्तव में * विशेष रूप से *" असली "कीवर्ड तर्कों के लिए माइग्रेशन पथ के रूप में पेश किया गया था। –

2

लघु संस्करण होगा क्योंकि Matz तो कहते हैं - इस RubyMine पर issue वह टिप्पणी

मैं प्रस्ताव के लिए नकारात्मक है। मेरी राय यह है कि आपको कीवर्ड के रूप में तारों का उपयोग नहीं करना चाहिए (या अब नहीं)।

यह वास्तविक समस्या कुछ के आसपास होती है जो इसके परिणामस्वरूप होती है, लेकिन यदि मैटज़ कहता है कि ऐसा होने की संभावना नहीं है। मुझे नहीं पता कि क्या उसने आगे बढ़ाया है कि वह इसके खिलाफ क्यों है।

2

* और ** के कार्यान्वयन प्रासंगिक हो सकता है:

def gather_arguments(*arguments, **keywords) 
    puts "arguments: #{arguments.inspect}" 
    puts " keywords: #{keywords.inspect}" 
end 

gather_arguments('foo' => 1, bar: 2, 'baz' => 3, qux: 4) 

आउटपुट:

arguments: [{"foo"=>1, "baz"=>3}] 
keywords: {:bar=>2, :qux=>4} 
+0

क्या आप कह रहे हैं कि स्ट्रिंग कुंजी आरक्षित हैं ताकि वे विशिष्ट रूप से कीवर्ड तर्क तर्क हो और हैश तर्कों के हिस्से के रूप में व्याख्या की जा सकें? यदि ऐसा है, तो मैं सहमत नहीं हूं। – sawa

+1

@ सावा मैं यह नहीं कह रहा हूं कि यही कारण है। स्ट्रिंग कुंजियों के साथ कीवर्ड तर्कों की अनुमति होने पर बस '*' और '**' का मौजूदा व्यवहार बदल जाएगा (और संभवतः मौजूदा कोड तोड़ सकता है)। – Stefan

संबंधित मुद्दे