Faraday: फ़ीचर अनुरोध: HTTP क्रियाओं के लिए स्पष्ट विधि defs

हाय @dduugg , विधियों को स्पष्ट रूप से परिभाषित करने के बजाय, मैं एक दस्तावेज़-अनुकूल समाधान का पता
हम कनेक्शन में मेटा-प्रोग्रामिंग परिभाषा का भी उपयोग करते हैं: https://github.com/lostisland/faraday/blob/master/lib/faraday/connection.rb#L195

क्या यह आपके द्वारा ऊपर बताए गए बिंदुओं के साथ अच्छी तरह से काम करता है?
यदि ऐसा है, तो हम Faraday मॉड्यूल के लिए भी इसी तरह के दस्तावेज़ीकरण स्निपेट को दोहरा सकते हैं।

हाय @iMacTia , उत्तर के लिए धन्यवाद। मुझे नहीं लगता कि समस्या दस्तावेज़ीकरण के साथ हल करने योग्य है। क्या मैं आपको स्पष्ट परिभाषाओं के प्रतिरोध के बारे में विस्तार से बताने के लिए परेशान कर सकता हूँ? मुझे लगता है कि यह चर्चा को बेहतर ढंग से तैयार करेगा। उदाहरण के लिए, एक दस्तावेज़ीकरण दृष्टिकोण सात एक-पंक्ति स्पष्ट फ़ॉरवर्डिंग डीफ़ की तुलना में वर्बोज़ (विभिन्न @!method & @!scope निर्देशों के अलावा, method_missing कोड की गणना) के रूप में होने की संभावना है मैं Faraday पर सुझाव दे रहा हूं। लेकिन मुझे नहीं पता कि यह तर्क यहाँ है (कोड लिखे जाने की तुलना में बहुत अधिक पढ़ा जाता है, इसलिए मुझे लगता है कि कोड लेखक के लिए अनुकूलन वैसे भी त्रुटि में है)।

मुख्य रूप से 2 बिंदु हैं जिन्होंने मुझे इस बदलाव के साथ बाड़ पर खड़ा कर दिया है।

• मुझे व्यक्तिगत रूप से नहीं लगता कि delegates का उपयोग करना केवल कोड लेखक के लिए एक फायदा है। मैं वर्षों से रूबी का उपयोग कर रहा हूं और दूसरों की तरह मैं इस भाषा के संक्षिप्त वाक्य-विन्यास की सराहना करने आया हूं। जब मैं कुछ कोड पढ़ता हूं और मुझे delegates मुझे तुरंत पता चल जाता है कि इसका क्या मतलब है और यह संभावित रूप से कोड की दसियों पंक्तियों को उनमें से केवल एक जोड़े में संघनित कर सकता है।
• फैराडे में HTTP क्रिया प्रॉक्सी एकमात्र उदाहरण नहीं है जहां हम मेटाप्रोग्रामिंग का लाभ उठाते हैं, ऐसे कई और उदाहरण हैं, जो संभवत: उसी मुद्दे से ग्रस्त हैं जो आपने यहां उठाया है, लेकिन अभी तक ध्यान नहीं दिया गया है। इस परिवर्तन के लिए सहमत होने से या तो एक अपवाद बन जाएगा या एक मिसाल कायम हो जाएगी, दोनों चीजें जिनसे मैं बचना चाहता हूं।

लेकिन इस बदलाव के प्रति अपने प्रतिरोध पर ध्यान केंद्रित करने के बजाय, मैं इस बारे में चर्चा करना चाहूंगा कि हम यहां किस तरह के फायदे पेश करने की कोशिश कर रहे हैं। मैं आपके द्वारा वर्णित समस्या को पूरी तरह से समझता हूं और मुझे वास्तव में लगता है कि यदि संभव हो तो हमें इसे हल करने का प्रयास करना चाहिए!
तो अगर यहां मुख्य मुद्दा कोड सुझावों, स्वत: पूर्ण और दस्तावेज़ीकरण के लिए आईडीई/टूल्स के साथ संगतता है, तो मैं केवल दस्तावेज़ीकरण टिप्पणियों जैसे वैकल्पिक समाधान खोजने का प्रस्ताव कर रहा हूं (हम पहले से ही यार्ड का काफी व्यापक रूप से उपयोग करते हैं)।
और आप भी सही हैं जब आप कहते हैं कि यह समाधान वर्बोज़ जैसा है, हालांकि मैं तर्क दूंगा कि एक टिप्पणी पठनीयता को उतना प्रभावित नहीं करेगी जितनी विधियों की सूची और यह आसानी से पहचानने योग्य है।

हाय @iMacTia , आपके उत्तर के लिए धन्यवाद। हमने बेहतर एपीआई खोज योग्यता और टूलिंग समर्थन के साथ एक अलग पुस्तकालय में स्विच किया है, लेकिन अगर आप उन्हें उपयोगी पाते हैं तो मैं अपने विचार साझा करूंगा।

• खोज योग्यता मेटाप्रोग्रामिंग के उपयोग को रोकती नहीं है (हालांकि इस विशिष्ट मामले में मुझे लगता है कि स्पष्ट def s जाने का रास्ता है), लेकिन इसे method_missing दृष्टिकोण को बदलने की आवश्यकता होगी, जैसा कि पहले वर्णित है।
• मुझे यकीन नहीं है कि मैं delegates तर्क को समझता हूं। फैराडे HTTP क्रिया विधियों को संभालने में स्पष्ट प्रतिनिधियों का उपयोग नहीं करता है। (इस बिंदु पर भ्रम शायद एक कोड गंध है कि HTTP क्रिया विधियों का कार्यान्वयन अत्यधिक जटिल है)।
• हमें असहमत होने के लिए सहमत होना होगा कि delegate और इस तरह के अन्य कोड लेखक के लिए एक सहायता हैं। मैं कुछ दशकों के सामूहिक रूबी अनुभव वाले लोगों के साथ काम कर रहा हूं, और हमें यहां दृष्टिकोण के लिए कोई पठनीयता लाभ नहीं मिला है (यहां तक ​​​​कि pry, YARD, शर्बत और सोलरग्राफ के माध्यम से एपीआई का पता लगाने की कोशिश करने में लगने वाले समय को भी छूट दी गई है) ) कम से कम इस विशिष्ट बिंदु पर, पहली बार इस एपीआई का पता लगाने के लिए एक रूबीवादी प्रयास को देखना सार्थक हो सकता है।

बस यहां कुछ ईमानदार (और उम्मीद के मुताबिक उपयोगी) प्रतिक्रिया देने की कोशिश कर रहा हूं। मैं अभी भी ओएसएस में इस योगदान पर समय और प्रयास की सराहना करता हूं।

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

@gurgeous मैं सहमत हूँ कि प्रलेखन निश्चित रूप से एक ऐसा मोर्चा है जहाँ हम एक बेहतर काम कर सकते हैं (हालाँकि हमने फैराडे वेबसाइट को लॉन्च करके इससे निपटना शुरू किया है), लेकिन मैं यह नहीं देखता कि इस मुद्दे में सुझाव आपके विशिष्ट बिंदु को कैसे हल करने वाला है।

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

इसलिए मुझे क्यों लगता है कि एक बेहतर दस्तावेज़ीकरण (दृश्य या कोड में) इसे हल करने का तरीका है।
लेकिन शायद मुझे यहाँ कुछ याद आ रहा है या कोई विशेष उपयोग-मामला जहाँ एक बेहतर दस्तावेज़ीकरण मदद नहीं करेगा?
क्या "खोज योग्यता" की मेरी समझ सही है?

क्या "खोज योग्यता" की मेरी समझ सही है?

मेरे मामले में नहीं। मेरी अपेक्षा ls Faraday में pry , उसके बाद $ Faraday.get , आदि करने में सक्षम होना था। अगर मैं एक विशिष्ट विधि में गोता लगाना चाहता था। मुझे लगता है कि मैं इसे किसी भी अन्य रत्न के साथ प्रभावी ढंग से करने में सक्षम हूं, जिसका मैंने उपयोग किया है, शायद ही कभी (यदि कभी) एक दस्तावेज पृष्ठ पर नेविगेट करने की आवश्यकता होती है, इसलिए इस टिकट को खोलना। (यह ऊपर वर्णित अन्य मुद्दों के अतिरिक्त है, जैसे कि स्थिर विश्लेषण उपकरण जो पुस्तकालय का उपयोग करने वाले कोड को पहचानने में विफल होते हैं।)

हमें सुनने के लिए फिर से धन्यवाद।

मुझे फैराडे वेबसाइट बहुत पसंद है! हो सकता है कि मैं कुछ सुझावों के साथ पीआर प्रस्तुत कर सकूं? मदद करने में खुशी हुई। मुझे लगता है कि इस तरह का प्रयास हमेशा नए लोगों के लिए फायदेमंद होता है। मुझे बताएं कि क्या आप रुचि रखते हैं।

pry + ls Faraday संदर्भ में, मैं भी उस पैटर्न का प्रशंसक हूं और इसका व्यापक रूप से उपयोग करता हूं। Method_missing से दूर जाना कोई बुरा विचार नहीं है। रूबी 3, भाषा सर्वर, आरबीएस इत्यादि के उदय के साथ रूबी धीरे-धीरे उस दिशा में खींची जा रही है। मुझे लगता है कि यह दस्तावेज़ों के लिए माध्यमिक है, हालांकि।

@gurgeous We _are_ दस्तावेज़ीकरण पुल अनुरोधों में रुचि रखते हैं, docs/ निर्देशिका को Gemfile (और README) के एक सेट के साथ खोजें, जिसका उपयोग वेबसाइट को GitHub पेज पर प्रकाशित करने के लिए किया जाता है, जिसका हम उपयोग कर रहे हैं। यदि इसका उपयोग स्पष्ट नहीं है, तो वेबसाइट अपडेट करने की प्रक्रिया, कृपया _that_ के लिए कोई समस्या या पीआर भी खोलें।

फैराडे उपयोगकर्ताओं की देखभाल करने के लिए धन्यवाद!

मुझे फैराडे वेबसाइट बहुत पसंद है! हो सकता है कि मैं कुछ सुझावों के साथ पीआर प्रस्तुत कर सकूं? मदद करने में खुशी हुई। मुझे लगता है कि इस तरह का प्रयास हमेशा नए लोगों के लिए फायदेमंद होता है। मुझे बताएं कि क्या आप रुचि रखते हैं।

@गर्जियस बिल्कुल! हम हमेशा दस्तावेज़ीकरण या वेबसाइट को बेहतर बनाने में मदद का स्वागत करते हैं, क्योंकि जो चीजें हमारे लिए स्पष्ट हैं वे रखरखाव करने वालों के लिए उपयोगकर्ताओं के लिए स्पष्ट नहीं हो सकती हैं। साथ ही हम वास्तव में समय के साथ संघर्ष करते हैं और यह अक्सर प्रलेखन के लिए एक कीमत पर आता है। वास्तव में, प्रलेखन बहुत खराब स्थिति में होगा यदि यह @olleolleolle निरंतर प्रयासों के लिए नहीं था !

pry बिंदु (cc @dduugg) पर, मैंने कभी इसका उपयोग नहीं किया इसलिए मैं शायद समझने में असफल रहा।
मैंने अभी इसे आपके अतिरिक्त विवरणों के साथ आज़माया है और मैंने देखा है कि ls Faraday::Connection गतिशील रूप से जेनरेट की गई विधियों के साथ-साथ प्रत्यायोजित विधियों को भी दिखाता है।
तो मेरी मूल समझ है कि हम इस तरह के रूबी "जादू" का उपयोग नहीं कर सकते हैं, और वास्तव में केवल missing_method का उपयोग करने की सीमा है।

जो मुझे बहुत पसंद नहीं था, वह था निम्नलिखित जैसे स्पष्ट तरीकों का परिचय:

def self.get(...)
  ...
end

def self.post(...)
  ...
end

# ... and so on ...

लेकिन अगर हम मुख्य Faraday मॉड्यूल में गतिशील परिभाषाओं या प्रतिनिधिमंडलों को जोड़कर pry की खोज को ठीक कर सकते हैं, तो यह कुछ ऐसा है जिसके साथ मैं ठीक रहूंगा। पहली बार नहीं मिलने के लिए खेद है!

समय की कमी की कोई चिंता नहीं। ओपन सोर्स मेंटेनर होने के लिए कभी भी बुरा मत मानना! हम परवाह किए बिना आपके प्रयासों की सराहना करते हैं। मैं वहां भी गया हूं...

मैं एक चर्चा फिर से शुरू करूंगा: डॉक्स यह सुनिश्चित करने के लिए कि हम एक ही पृष्ठ पर हैं।

@iMacTia एक उपयोगकर्ता को Faraday::Connection में देखने के बारे में कैसे पता चलेगा? मैंने तब से एक खोज योग्य एपीआई के साथ एक HTTP मणि पर स्विच किया है, लेकिन मैंने https://lostisland.github.io/faraday/usage/ पर एक त्वरित नज़र Faraday पर स्थिर तरीकों का आह्वान करते हैं, लेकिन वे pry में नहीं पाए जाते हैं। मैं किसी अन्य रत्न के बारे में नहीं जानता जिसने इस दृष्टिकोण को अपनाया है, और मैं अभी भी यह मानता हूं कि यह एक विरोधी पैटर्न है।

धन्यवाद, हमेशा की तरह, मुझे सुनने के लिए।