CL https://golang.org/cl/22057 में इस मुद्दे का उल्लेख है।

मुझे अपनी https://golang.org/wiki/NoMeToo नीति के बारे में पहले से ही याद दिला दें। इमोजी पार्टी ऊपर है।

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

लिंक किए गए प्रस्ताव में दो "आवश्यकताएं" हैं जो कार्यान्वयन को जटिल बना सकती हैं और प्रकार की सुरक्षा को कम कर सकती हैं:

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

इन आवश्यकताओं को बाहर करने के लिए प्रतीत होता है जैसे कि रस्ट की विशेषता प्रणाली के समान एक प्रणाली, जहां सामान्य प्रकार विशेषता सीमा से विवश हैं। इनकी आवश्यकता क्यों है?

मानक पुस्तकालय में जेनरिक को बहुत निम्न स्तर पर बनाना आकर्षक हो जाता है, जैसा कि C++ std::basic_string में है, एसटीडी :: आवंटक>. इसके अपने फायदे हैं-अन्यथा कोई भी ऐसा नहीं करेगा-लेकिन इसका व्यापक और कभी-कभी आश्चर्यजनक प्रभाव पड़ता है, जैसा कि समझ से बाहर सी ++ त्रुटि संदेशों में होता है।

C++ में समस्या टाइप चेकिंग जेनरेट कोड से उत्पन्न होती है। कोड जनरेशन से पहले एक अतिरिक्त प्रकार की जांच करने की आवश्यकता है। सी ++ अवधारणा प्रस्ताव जेनेरिक कोड के लेखक को सामान्य प्रकार की आवश्यकताओं को निर्दिष्ट करने की अनुमति देकर इसे सक्षम बनाता है। इस तरह, कोड जनरेशन से पहले संकलन टाइप चेकिंग में विफल हो सकता है और सरल त्रुटि संदेश मुद्रित किए जा सकते हैं। सी ++ जेनरिक (अवधारणाओं के बिना) के साथ समस्या यह है कि सामान्य कोड _is_ सामान्य प्रकार का विनिर्देश है। यही कारण है कि समझ से बाहर त्रुटि संदेश बनाता है।

जेनेरिक कोड एक सामान्य प्रकार का विनिर्देश नहीं होना चाहिए।

@tamird यह गो के इंटरफ़ेस प्रकारों की एक अनिवार्य विशेषता है कि आप एक गैर-इंटरफ़ेस प्रकार T को परिभाषित कर सकते हैं और बाद में एक इंटरफ़ेस प्रकार I को परिभाषित कर सकते हैं जैसे कि T I लागू करता है। देखें https://golang.org/doc/faq#implements_interface । यह असंगत होगा यदि गो ने जेनरिक का एक रूप लागू किया जिसके लिए एक सामान्य प्रकार जी का उपयोग केवल एक प्रकार टी के साथ किया जा सकता है जिसमें स्पष्ट रूप से कहा गया है "मुझे जी को लागू करने के लिए इस्तेमाल किया जा सकता है।"

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

@ianlancetaylor https://doc.rust-lang.org/book/traits.html रस्ट के लक्षणों की व्याख्या करता है। जबकि मुझे लगता है कि वे सामान्य रूप से एक अच्छे मॉडल हैं, वे गो के लिए एक खराब फिट होंगे क्योंकि यह आज भी मौजूद है।

@sbunc मैंने यह भी सोचा था कि अवधारणाएं उत्तर थीं, और आप पिछले प्रस्तावों से पहले विभिन्न प्रस्तावों के माध्यम से बिखरे हुए विचार को देख सकते हैं। लेकिन यह हतोत्साहित करने वाला है कि अवधारणाओं को मूल रूप से सी ++ 11 बनने के लिए योजना बनाई गई थी, और अब यह 2016 है, और वे अभी भी विवादास्पद हैं और विशेष रूप से सी ++ भाषा में शामिल होने के करीब नहीं हैं।

क्या दृष्टिकोणों के मूल्यांकन पर किसी मार्गदर्शन के लिए अकादमिक साहित्य का कोई महत्व होगा?

इस विषय पर मैंने जो एकमात्र पेपर पढ़ा है, क्या डेवलपर्स सामान्य प्रकारों से लाभान्वित होते हैं? (पेवॉल सॉरी, आप गूगल पर एक पीडीएफ डाउनलोड कर सकते हैं) जिसमें निम्नलिखित कहने के लिए था

नतीजतन, प्रयोग की एक रूढ़िवादी व्याख्या
यह है कि सामान्य प्रकारों को ट्रेडऑफ़ के रूप में माना जा सकता है
सकारात्मक प्रलेखन विशेषताओं और के बीच
नकारात्मक एक्स्टेंसिबिलिटी विशेषताओं। का रोमांचक हिस्सा
अध्ययन यह है कि यह एक ऐसी स्थिति को दर्शाता है जहां a . का उपयोग किया जाता है
(मजबूत) स्थिर प्रकार की प्रणाली का नकारात्मक प्रभाव पड़ा
विकास समय जबकि एक ही समय में अपेक्षित लाभ-
फिट - टाइप एरर फिक्सिंग टाइम में कमी - दिखाई नहीं दी।
हमें लगता है कि इस तरह के कार्य भविष्य के प्रयोगों में मदद कर सकते हैं
प्रकार प्रणालियों के प्रभाव की पहचान करना।

मैं यह भी देखता हूं https://github.com/golang/go/issues/15295 लाइटवेट, फ्लेक्सिबल ऑब्जेक्ट-ओरिएंटेड जेनरिक का भी संदर्भ देता है।

यदि हम निर्णय का मार्गदर्शन करने के लिए शिक्षाविदों पर निर्भर होने जा रहे थे, तो मुझे लगता है कि एक अप फ्रंट साहित्य समीक्षा करना बेहतर होगा, और संभवत: जल्द ही निर्णय लें कि क्या हम सबूतों पर निर्भर लोगों से अलग अनुभवजन्य अध्ययनों का वजन करेंगे।

कृपया देखें: http://dl.acm.org/citation.cfm?id=2738008 बारबरा लिस्कोव द्वारा:

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

मुझे लगता है कि उन्होंने वहां जो किया वह बहुत अच्छा है - मुझे खेद है कि यह रुकने के लिए गलत जगह है, लेकिन मुझे/प्रस्तावों में टिप्पणी करने के लिए जगह नहीं मिली और मुझे यहां कोई उपयुक्त मुद्दा नहीं मिला।

एक या एक से अधिक प्रयोगात्मक ट्रांसपिलर रखना दिलचस्प हो सकता है - गो 1.xy स्रोत कोड कंपाइलर के लिए एक सामान्य जेनेरिक स्रोत कोड।
मेरा मतलब है - मेरी राय के लिए बहुत अधिक बात/तर्क, और कोई भी स्रोत कोड नहीं लिख रहा है कि _try_ गो के लिए जेनेरिक के _some दयालु_ को लागू करने के लिए।

बस गो और जेनरिक के साथ ज्ञान और अनुभव प्राप्त करने के लिए - यह देखने के लिए कि क्या काम करता है और क्या नहीं।
यदि सभी गो जेनरिक समाधान वास्तव में अच्छे नहीं हैं, तो; गो के लिए कोई जेनरिक नहीं।

क्या प्रस्ताव में द्विआधारी आकार और स्मृति पदचिह्न पर प्रभाव भी शामिल हो सकते हैं? मैं उम्मीद करता हूं कि प्रत्येक ठोस मूल्य प्रकार के लिए कोड डुप्लिकेशन होगा ताकि कंपाइलर अनुकूलन उन पर काम कर सके। मुझे इस बात की गारंटी की उम्मीद है कि कंक्रीट पॉइंटर प्रकारों के लिए कोई कोड दोहराव नहीं होगा।

मैं एक पुघ निर्णय मैट्रिक्स प्रदान करता हूं। मेरे मानदंड में स्पष्ट प्रभाव (स्रोत जटिलता, आकार) शामिल हैं। मैंने मानदंड के लिए भार निर्धारित करने के लिए मानदंड को भी मजबूर किया। आपका अपना निश्चित रूप से भिन्न हो सकता है। मैंने डिफ़ॉल्ट विकल्प के रूप में "इंटरफ़ेस" का उपयोग किया और इसकी तुलना "कॉपी/पेस्ट" जेनरिक, टेम्प्लेट आधारित जेनरिक से की (मेरे मन में कुछ ऐसा था जैसे डी भाषा कैसे काम करती है), और कुछ जिसे मैंने रनटाइम इंस्टेंटेशन स्टाइल जेनरिक कहा। मुझे यकीन है कि यह एक बहुत बड़ा सरलीकरण है। फिर भी, यह विकल्पों का मूल्यांकन करने के बारे में कुछ विचार पैदा कर सकता है ... यह मेरी Google शीट का एक सार्वजनिक लिंक होना चाहिए, यहां

पिंगिंग @yizhouzhang और @andrewcmyers ताकि वे गो में जेनरिक जैसे जीनस के बारे में अपनी राय दे सकें। ऐसा लगता है कि यह एक अच्छा मैच हो सकता है :)

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

यहां उस पेपर का लिंक दिया गया है जिसके लिए ACM डिजिटल लाइब्रेरी एक्सेस की आवश्यकता नहीं है:
http://www.cs.cornell.edu/andru/papers/genus/

जीनस होम पेज यहाँ है: http://www.cs.cornell.edu/projects/genus/

हमने अभी तक कंपाइलर को सार्वजनिक रूप से जारी नहीं किया है, लेकिन हम इसे बहुत जल्द करने की योजना बना रहे हैं।

लोगों के किसी भी प्रश्न का उत्तर देने में खुशी होती है।

@mandolyte के निर्णय मैट्रिक्स के संदर्भ में, जीनस का स्कोर 17 है, जो #1 के बराबर है। हालांकि, मैं स्कोर करने के लिए कुछ और मानदंड जोड़ूंगा। उदाहरण के लिए, मॉड्यूलर प्रकार की जाँच महत्वपूर्ण है, जैसा कि अन्य जैसे @sbunc ऊपर देखा गया है, लेकिन टेम्पलेट-आधारित योजनाओं में इसकी कमी है। विभिन्न जेनरिक डिजाइनों की तुलना करते हुए, जीनस पेपर की तकनीकी रिपोर्ट में पृष्ठ 34 पर एक बहुत बड़ी तालिका है।

मैंने अभी -अभी गो जेनरिक दस्तावेज़ का संपूर्ण सारांश पढ़ा , जो पिछली चर्चाओं का एक सहायक सारांश था। मेरे विचार से Genus में जेनरिक तंत्र C++, Java, या C# के लिए पहचानी गई समस्याओं से ग्रस्त नहीं है। जावा के विपरीत, जीनस जेनरिक को संशोधित किया जाता है, ताकि आप रन टाइम पर प्रकारों का पता लगा सकें। आप आदिम प्रकारों पर भी तत्काल कर सकते हैं, और आपको उन जगहों पर अंतर्निहित मुक्केबाजी नहीं मिलती है जिन्हें आप वास्तव में नहीं चाहते हैं: टी के सरणी जहां टी एक आदिम है। टाइप सिस्टम हास्केल और रस्ट के सबसे करीब है - वास्तव में थोड़ा अधिक शक्तिशाली है, लेकिन मुझे लगता है कि यह भी सहज है। आदिम विशेषज्ञता ala C# वर्तमान में Genus में समर्थित नहीं है, लेकिन यह हो सकता है। ज्यादातर मामलों में, विशेषज्ञता को लिंक समय पर निर्धारित किया जा सकता है, इसलिए सही रन-टाइम कोड जनरेशन की आवश्यकता नहीं होगी।

CL https://golang.org/cl/22163 इस मुद्दे का उल्लेख करता है।

सामान्य प्रकारों को सीमित करने का एक तरीका जिसमें नई भाषा अवधारणाओं को जोड़ने की आवश्यकता नहीं है: https://docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit?usp=sharing।

जीनस वास्तव में अच्छा दिखता है और यह स्पष्ट रूप से कला की एक महत्वपूर्ण प्रगति है, लेकिन मैं यह नहीं देखता कि यह गो पर कैसे लागू होगा। क्या किसी के पास इस बात का एक स्केच है कि यह गो टाइप सिस्टम/दर्शन के साथ कैसे एकीकृत होगा?

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

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

@andrewcmyers उम्मीद करते हैं कि @ianlancetaylor उस पर आपके साथ काम करेगा। देखने के लिए बस कुछ उदाहरण होने से बहुत मदद मिलेगी।

मैंने जीनस पेपर के माध्यम से पढ़ा है। जिस हद तक मैं इसे समझता हूं, यह जावा के लिए अच्छा लगता है, लेकिन यह गो के लिए स्वाभाविक रूप से उपयुक्त नहीं लगता।

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

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

इन विचारों को गो पर लागू होते देखना दिलचस्प होगा, लेकिन मैं परिणाम के बारे में आशावादी नहीं हूं।

मैं गो विशेषज्ञ नहीं हूं, लेकिन इसकी प्रकार प्रणाली प्री-जेनेरिक जावा की तुलना में कोई आसान नहीं लगती है। टाइप सिंटैक्स एक अच्छे तरीके से थोड़ा हल्का-वजन वाला है लेकिन अंतर्निहित जटिलता लगभग समान है।

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

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

सापेक्ष जटिलता एक तरफ, वे काफी भिन्न हैं कि जीनस 1: 1 का नक्शा नहीं बना सका। कोई सबटाइपिंग बड़ा नहीं लगता।

अगर आप रुचि रखते है:

मेरे द्वारा उल्लिखित प्रासंगिक दार्शनिक/डिज़ाइन मतभेदों का संक्षिप्त सारांश निम्नलिखित एफएक्यू प्रविष्टियों में निहित है:

• https://golang.org/doc/faq#implements_interface
• https://golang.org/doc/faq#overloading
• https://golang.org/doc/faq#covariant_types
• https://golang.org/doc/faq#variant_types

अधिकांश भाषाओं के विपरीत, गो स्पेक https://golang.org/ref/spec#Constants से शुरू होने वाले टाइप सिस्टम के प्रासंगिक गुणों के बारे में बहुत छोटा और स्पष्ट है और सीधे "ब्लॉक्स" शीर्षक वाले अनुभाग तक जाता है (जिनमें से सभी 11 पृष्ठों से कम मुद्रित है)।

Java और C# जेनरिक के विपरीत, Genus जेनरिक मैकेनिज्म सबटाइपिंग पर आधारित नहीं है। दूसरी ओर, मुझे ऐसा लगता है कि गो में सबटाइपिंग है, लेकिन स्ट्रक्चरल सबटाइपिंग है। यह जीनस दृष्टिकोण के लिए भी एक अच्छा मेल है, जिसमें पूर्व-घोषित संबंधों पर निर्भर होने के बजाय एक संरचनात्मक स्वाद है।

मुझे विश्वास नहीं है कि गो में स्ट्रक्चरल सबटाइपिंग है।

जबकि दो प्रकार जिनके अंतर्निहित प्रकार समान हैं इसलिए समान हैं
एक दूसरे के लिए प्रतिस्थापित किया जा सकता है, https://play.golang.org/p/cT15aQ-PFr

यह उन दो प्रकारों तक विस्तारित नहीं होता है जो फ़ील्ड का एक सामान्य उपसमुच्चय साझा करते हैं,
https://play.golang.org/p/KrC9_BDXuh।

थू, अप्रैल 28, 2016 अपराह्न 1:09 बजे, एंड्रयू मायर्स नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment -215298127

धन्यवाद, जब मैं इंटरफेस लागू करता हूं तो मैं कुछ भाषा की गलत व्याख्या कर रहा था। वास्तव में, यह मुझे ऐसा लगता है जैसे गो इंटरफेस, एक मामूली विस्तार के साथ, जीनस-शैली की बाधाओं के रूप में इस्तेमाल किया जा सकता है।

यही कारण है कि मैंने आपको पिंग किया, जीनस जावा/सी # जेनेरिक की तरह एक बेहतर दृष्टिकोण की तरह लगता है।

इंटरफ़ेस प्रकारों पर विशेषज्ञता के संबंध में कुछ विचार थे; उदाहरण के लिए _पैकेज टेम्प्लेट_ दृष्टिकोण "प्रस्ताव" 1 2 इसके उदाहरण हैं।

टीएल; डॉ; इंटरफ़ेस विशेषज्ञता के साथ सामान्य पैकेज इस तरह दिखेगा:

package set
type E interface { Equal(other E) bool }
type Set struct { items []E }
func (s *Set) Add(item E) { ... }

संस्करण 1. पैकेज के दायरे में विशेषज्ञता के साथ:

package main
import items set[[E: *Item]]

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs items.Set
xs.Add(&Item{})

संस्करण 2. घोषणा क्षेत्र विशेषज्ञता:

package main
import set

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs set.Set[[E: *Item]]
xs.Add(&Item{})

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

डिक्लेरेशन स्कोप्ड स्पेशलाइजेशन की कीमत पर अधिक संभावनाएं हैं, जिससे इसका दुरुपयोग होने की संभावना अधिक हो जाती है और यह अधिक क्रियात्मक है। लेकिन, कार्यात्मक कोड संभव होगा, जैसे:

type E interface{}
func Reduce(zero E, items []E, fn func(a, b E) E) E { ... }

Reduce[[E: int]](0, []int{1,2,3,4}, func(a, b int)int { return a + b } )
// there are probably ways to have some aliases (or similar) to make it less verbose
alias ReduceInt Reduce[[E: int]]
func ReduceInt Reduce[[E: int]]

इंटरफ़ेस विशेषज्ञता दृष्टिकोण में दिलचस्प गुण हैं:

• इंटरफेस का उपयोग करने वाले पहले से मौजूद पैकेज विशेषज्ञ होंगे। उदाहरण के लिए मैं sort.Sort[[Interface:MyItems]](...) पर कॉल करने में सक्षम हूं और इंटरफ़ेस के बजाय ठोस प्रकार पर सॉर्टिंग कार्य कर सकता हूं (इनलाइनिंग से संभावित लाभ के साथ)।
• परीक्षण सरल है, मुझे केवल यह आश्वस्त करना है कि जेनेरिक कोड इंटरफेस के साथ काम करता है।
• यह बताना आसान है कि यह कैसे काम करता है। यानी कल्पना करें कि [[E: int]] E int से बदल देता है।

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

type op
import "set"

type E interface{}
func Union(a, b set.Set[[set.E: E]]) set.Set[[set.E: E]] {
    result := set.New[[set.E: E]]()
    ...
}

_बेशक, लागू करने की तुलना में पूरी बात बताना आसान है। आंतरिक रूप से शायद कई समस्याएं हैं और यह कैसे काम कर सकता है।_

_PS, धीमी जेनरिक प्रगति पर बड़बड़ाने वालों के लिए, मैं उन मुद्दों पर अधिक समय बिताने के लिए गो टीम की सराहना करता हूं, जिनका समुदाय को बड़ा लाभ होता है जैसे कंपाइलर/रनटाइम बग, SSA, GC, http2._

@egonelbre आपकी बात है कि पैकेज-स्तरीय जेनरिक "दुरुपयोग" को रोकेगा, वास्तव में एक महत्वपूर्ण है जिसे मुझे लगता है कि ज्यादातर लोग अनदेखी करते हैं। इसके अलावा उनकी सापेक्ष अर्थपूर्ण और वाक्य-विन्यास सादगी (केवल पैकेज और आयात संरचनाएँ प्रभावित होती हैं) उन्हें गो के लिए बहुत आकर्षक बनाती हैं।

@andrewcymyers दिलचस्प है कि आपको लगता है कि गो इंटरफेस जीनस-शैली की बाधाओं के रूप में काम करते हैं। मैंने सोचा होगा कि उन्हें अभी भी समस्या है कि आप उनके साथ बहु-प्रकार-पैरामीटर बाधाओं को व्यक्त नहीं कर सकते हैं।

हालाँकि, एक बात जो मैंने अभी महसूस की है, वह यह है कि गो में आप एक इंटरफ़ेस इनलाइन लिख सकते हैं। तो सही सिंटैक्स के साथ आप इंटरफ़ेस को सभी मापदंडों के दायरे में रख सकते हैं और बहु-पैरामीटर बाधाओं को पकड़ सकते हैं:

टाइप करें [वी, ई] ग्राफ [वी इंटरफेस {एज () ई}, ई इंटरफेस {एंडपॉइंट्स () (वी, वी)}] ...

मुझे लगता है कि बाधाओं के रूप में इंटरफेस के साथ बड़ी समस्या यह है कि जावा में गो में विधियां व्यापक नहीं हैं। अंतर्निर्मित प्रकारों में विधियां नहीं होती हैं। Java.lang.Object जैसे सार्वभौमिक तरीकों का कोई सेट नहीं है। उपयोगकर्ता आमतौर पर समान या हैशकोड जैसी विधियों को उनके प्रकारों पर परिभाषित नहीं करते हैं, जब तक कि उन्हें विशेष रूप से आवश्यकता न हो, क्योंकि वे विधियां मानचित्र कुंजियों के रूप में उपयोग के लिए एक प्रकार को योग्य नहीं बनाती हैं, या किसी भी एल्गोरिदम में समानता की आवश्यकता होती है।

(गो में समानता एक दिलचस्प कहानी है। यदि भाषा कुछ आवश्यकताओं को पूरा करती है तो भाषा आपका प्रकार "==" देती है (देखें https://golang.org/ref/spec#Logical_operators, "comparable" खोजें)। कोई भी प्रकार " ==" मानचित्र कुंजी के रूप में काम कर सकता है। लेकिन यदि आपका प्रकार "==" के लायक नहीं है, तो ऐसा कुछ भी नहीं है जिसे आप लिख सकते हैं जो इसे मानचित्र कुंजी के रूप में काम करेगा।)

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

जाने का दूसरा तरीका उन तरीकों को जोड़ना है जिनमें उनकी कमी है। आप इसे मौजूदा भाषा में जावा की तुलना में बहुत हल्के तरीके से कर सकते हैं:

इंट इंट टाइप करें
func (i Int) कम (j Int) बूल {रिटर्न i < j}

Int प्रकार int के सभी ऑपरेटरों और अन्य गुणों को "विरासत में मिला" देता है। हालाँकि आपको Int और int को एक साथ उपयोग करने के लिए दोनों के बीच डालना होगा, जो एक दर्द हो सकता है।

जीनस मॉडल यहां मदद कर सकते हैं। लेकिन उन्हें बहुत सरल रखना होगा। मुझे लगता है कि अधिक कोड, कम प्रकार लिखने के रूप में गो के अपने चरित्र चित्रण में @ianlancetaylor बहुत संकीर्ण था। सामान्य सिद्धांत यह है कि गो जटिलता से घृणा करता है। हम जावा और सी ++ को देखते हैं और वहां कभी नहीं जाने के लिए दृढ़ संकल्प हैं। (कोई अपराध नहीं।)

तो मॉडल जैसी सुविधा के लिए एक त्वरित विचार यह होगा: क्या उपयोगकर्ता ऊपर इंट जैसे प्रकार लिखता है, और सामान्य तत्कालताओं में "int के साथ int" की अनुमति देता है, जिसका अर्थ है int प्रकार का उपयोग करें लेकिन इसे इंट की तरह व्यवहार करें। फिर कोई भी स्पष्ट भाषा निर्माण नहीं है जिसे मॉडल कहा जाता है, इसके कीवर्ड, इनहेरिटेंस सेमेन्टिक्स, और इसी तरह। मैं यह जानने के लिए मॉडलों को अच्छी तरह से नहीं समझता कि क्या यह संभव है, लेकिन यह गो की भावना में अधिक है।

@jba हम निश्चित रूप से जटिलता से बचने के सिद्धांत से सहमत हैं। "जितना संभव हो उतना सरल लेकिन आसान नहीं।" मैं शायद उन आधारों पर गो से कुछ जीनस सुविधाओं को छोड़ दूंगा, कम से कम पहले।

Genus दृष्टिकोण के बारे में एक अच्छी बात यह है कि यह अंतर्निहित प्रकारों को सुचारू रूप से संभालता है। याद रखें कि जावा में आदिम प्रकारों में विधियाँ नहीं होती हैं, और जीनस को यह व्यवहार विरासत में मिलता है। इसके बजाय, जीनस आदिम प्रकारों का व्यवहार करता है _as if_ उनके पास संतोषजनक बाधाओं के उद्देश्य के लिए विधियों का काफी बड़ा सूट था। एक हैश तालिका के लिए आवश्यक है कि इसकी चाबियों को हैश किया जा सके और तुलना की जा सके, लेकिन सभी आदिम प्रकार इस बाधा को पूरा करते हैं। तो Map[int, boolean] जैसे इंस्टेंटेशन टाइप करें बिना किसी और उपद्रव के पूरी तरह से कानूनी हैं। इसे प्राप्त करने के लिए पूर्णांक के दो स्वादों (int बनाम Int) के बीच अंतर करने की कोई आवश्यकता नहीं है। हालांकि, अगर इंट कुछ उपयोगों के लिए पर्याप्त संचालन से लैस नहीं थे, तो हम लगभग एक मॉडल का उपयोग करेंगे जैसे ऊपर इंट का उपयोग।

ध्यान देने योग्य एक और बात जीनस में "प्राकृतिक मॉडल" का विचार है। आपको सामान्य रूप से एक सामान्य प्रकार का उपयोग करने के लिए एक मॉडल घोषित करने की आवश्यकता नहीं है: यदि प्रकार तर्क बाधा को संतुष्ट करता है, तो एक प्राकृतिक मॉडल स्वचालित रूप से उत्पन्न होता है। हमारा अनुभव यह है कि यह सामान्य मामला है; स्पष्ट, नामित मॉडल घोषित करने की आमतौर पर आवश्यकता नहीं होती है। लेकिन अगर एक मॉडल की आवश्यकता होती है - उदाहरण के लिए, यदि आप एक गैर-मानक तरीके से हैश इनट्स करना चाहते हैं - तो सिंटैक्स आपके द्वारा सुझाए गए समान है: मानचित्र [intfancyHash, बूलियन के साथ] । मैं तर्क दूंगा कि सामान्य उपयोग के मामलों में जीनस वाक्य रचनात्मक रूप से हल्का होता है लेकिन जरूरत पड़ने पर रिजर्व में शक्ति के साथ।

@egonelbre जो आप यहां प्रस्तावित कर रहे हैं वह आभासी प्रकारों की तरह दिखता है, जो स्कैला द्वारा समर्थित हैं। क्रेस्टन क्रैब थोरुप का एक ECOOP'97 पेपर है, "जेनेरिसिटी इन जावा विथ वर्चुअल टाइप्स", जो इस दिशा की पड़ताल करता है। हमने अपने काम में आभासी प्रकार और आभासी कक्षाओं के लिए तंत्र भी विकसित किया ("J&: स्केलेबल सॉफ़्टवेयर संरचना के लिए नेस्टेड चौराहा", OOPSLA'06)।

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

// (जेनेरिक) फंक टाइप डेफिनिशन
Sum64 func (X, Y) फ्लोट64 टाइप करें {
फ्लोट 64 (एक्स) + फ्लोट 64 (वाई) लौटें
}

// तत्काल एक, स्थितिगत रूप से
मैं := 42
वर जे यूइंट = 86
योग := और योग64{i, j}

// पैरामीटर प्रकारों के नाम से एक को इंस्टेंट करें
योग: = और योग 64 {X: int, Y: uint}

// अब इसका इस्तेमाल करें ...
परिणाम: = योग (i, j) // परिणाम 128 है

इयान का प्रस्ताव बहुत ज्यादा मांग करता है। हम सभी सुविधाओं को एक साथ विकसित नहीं कर सकते, यह कई महीनों तक अधूरी स्थिति में रहेगा।

इस बीच, अधूरे प्रोजेक्ट को पूरा होने तक आधिकारिक गो भाषा नहीं कहा जा सकता क्योंकि इससे पारिस्थितिकी तंत्र को खंडित करने का जोखिम होगा।

तो सवाल यह है कि इसकी योजना कैसे बनाई जाए।

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

एक संभावित वाक्यविन्यास?

// Module defining generic type
module list(type t)

type node struct {
    next *node
    data t
}

// Module using generic type:
import (
    intlist "module/path/to/list" (int)
    funclist "module/path/to/list" (func (int) int)
)

l := intlist.New()
l.Insert(5)

@ md2perpe , वाक्य रचना इस मुद्दे का कठिन हिस्सा नहीं है। वास्तव में, यह अब तक का सबसे आसान है। कृपया ऊपर चर्चा और लिंक किए गए दस्तावेज़ देखें।

@ md2perpe हमने आंतरिक रूप से सामान्यता के तरीके के रूप में पूरे पैकेज ("मॉड्यूल") को पैरामीट्रिज़िंग पर चर्चा की है - यह वाक्य रचनात्मक ओवरहेड को कम करने का एक तरीका प्रतीत होता है। लेकिन इसके अन्य मुद्दे हैं; उदाहरण के लिए, यह स्पष्ट नहीं है कि कोई इसे उन प्रकारों के साथ कैसे पैरामीट्रिज करेगा जो पैकेज-स्तर नहीं हैं। लेकिन विचार अभी भी विस्तार से तलाशने लायक हो सकता है।

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

@thwd तो क्या पुस्तकालय लेखक इंटरफेस का उपयोग करना जारी रखेंगे, लेकिन बिना टाइप स्विचिंग और टाइप एसेसमेंट की आज जरूरत है। और क्या पुस्तकालय उपयोगकर्ता केवल ठोस प्रकारों में पास होगा जैसे कि पुस्तकालय इस प्रकार का उपयोग करेगा ... और फिर क्या संकलक दोनों को समेट लेगा? और अगर यह नहीं बता सकता कि क्यों? (जैसे कि मॉड्यूलो ऑपरेटर का उपयोग पुस्तकालय में किया गया था, लेकिन उपयोगकर्ता ने कुछ का एक टुकड़ा दिया।

क्या मैं करीब हूँ? :-)

@mandolyte हाँ! आइए इस धागे को प्रदूषित न करने के लिए ईमेल का आदान-प्रदान करें। आप मुझ तक "me at thwd dot me" पर संपर्क कर सकते हैं। कोई और इसे पढ़ रहा है जिसकी दिलचस्पी हो सकती है; मुझे एक ईमेल शूट करें और मैं आपको थ्रेड में जोड़ दूंगा।

यह type system और collection library के लिए एक शानदार विशेषता है।
एक संभावित वाक्यविन्यास:

type Element<T> struct {
    prev, next *Element<T>
    list *List<T>
    value T
}
type List<E> struct {
    root Element<E>
    len int
}

interface के लिए

type Collection<E> interface {
    Size() int
    Add(e E) bool
}

super type या type implement :

func contain(l List<parent E>, e E) bool
<V> func (c Collection<child E>)Map(fn func(e E) V) Collection

जावा में उपरोक्त उर्फ:

boolean contain(List<? super E>, E e)
<V> Collection Map(Function<? extend E, V> mapFunc);

@leaxoy जैसा कि पहले कहा गया था, वाक्य रचना यहाँ कठिन हिस्सा नहीं है। ऊपर चर्चा देखें।

बस इस बात से अवगत रहें कि इंटरफ़ेस की लागत अविश्वसनीय रूप से बहुत बड़ी है।

कृपया विस्तृत करें कि आपको क्यों लगता है कि इंटरफ़ेस की लागत "अविश्वसनीय" है
विशाल।
यह C++ के गैर-विशिष्ट वर्चुअल कॉल से भी बदतर नहीं होना चाहिए।

@minux मैं प्रदर्शन लागत के बारे में नहीं कह सकता लेकिन कोड गुणवत्ता के संबंध में। interface{} को संकलन समय पर सत्यापित नहीं किया जा सकता है लेकिन जेनरिक कर सकते हैं। मेरी राय में, ज्यादातर मामलों में, यह interface{} का उपयोग करने के प्रदर्शन के मुद्दों से अधिक महत्वपूर्ण है।

@xoviat

इसका वास्तव में कोई नकारात्मक पहलू नहीं है क्योंकि इसके लिए आवश्यक प्रसंस्करण संकलक को धीमा नहीं करता है।

(कम से कम) दो डाउनसाइड हैं।

लिंकर के लिए एक बढ़ा हुआ काम है: यदि दो प्रकार के विशेषज्ञता के परिणामस्वरूप एक ही अंतर्निहित मशीन कोड होता है, तो हम उस कोड की दो प्रतियों को संकलित और लिंक नहीं करना चाहते हैं।

दूसरा यह है कि पैरामीटरयुक्त पैकेज पैरामीटरयुक्त विधियों की तुलना में कम अभिव्यंजक होते हैं। (विस्तार के लिए पहली टिप्पणी से जुड़े प्रस्ताव देखें।)

क्या हाइपर टाइप एक अच्छा विचार है?

func getAddFunc (aType type) func(aType, aType) aType {
    return func(a, b aType) aType {
        return a+b
    }
}

क्या हाइपर टाइप एक अच्छा विचार है?

आप यहां जो वर्णन कर रहे हैं वह सिर्फ टाइप पैरामीटराइजेशन एला सी ++ (यानी, टेम्पलेट्स) है। यह मॉड्यूलर तरीके से टाइप-चेक नहीं करता है क्योंकि यह जानने का कोई तरीका नहीं है कि टाइप aType में दी गई जानकारी से + ऑपरेशन है। सीएलयू, हास्केल, जावा, जीनस के रूप में विवश प्रकार का पैरामीटर समाधान है।

@ golang101 मेरे पास उन पंक्तियों के साथ एक विस्तृत प्रस्ताव है। मैं इसे सूची में जोड़ने के लिए एक सीएल भेजूंगा, लेकिन इसे अपनाने की संभावना नहीं है।

CL https://golang.org/cl/38731 इस मुद्दे का उल्लेख करता है।

@andrewcmyers

यह मॉड्यूलर तरीके से टाइप-चेक नहीं करता है क्योंकि यह जानने का कोई तरीका नहीं है कि टाइप aType में दी गई जानकारी से + ऑपरेशन है।

ज़रूर है। वह बाधा फ़ंक्शन की परिभाषा में निहित है, और उस रूप की बाधाओं को getAddFunc के सभी (संक्रमणीय) संकलन-समय कॉल करने वालों के लिए प्रचारित किया जा सकता है।

बाधा गो _type_ का हिस्सा नहीं है - यानी, इसे भाषा के रन-टाइम हिस्से के प्रकार सिस्टम में एन्कोड नहीं किया जा सकता है - लेकिन इसका मतलब यह नहीं है कि इसका मूल्यांकन मॉड्यूलर फैशन में नहीं किया जा सकता है।

मेरे प्रस्ताव को 2016-09-compile-time-functions.md के रूप में जोड़ा गया।

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

@bcmills मुझे लगता है कि जेनरिक के किसी भी विचार के अलावा संकलन समय कार्य एक शक्तिशाली विचार है। उदाहरण के लिए, मैंने एक सुडोकू सॉल्वर लिखा है जिसे पॉपकाउंट की आवश्यकता है। इसे गति देने के लिए, मैंने विभिन्न संभावित मानों के लिए पॉपकाउंट का पूर्व-परिकलन किया और इसे गो स्रोत के रूप में संग्रहीत किया। यह कुछ ऐसा है जो कोई go:generate के साथ कर सकता है। लेकिन अगर कोई संकलन समय फ़ंक्शन था, तो उस लुकअप तालिका की गणना संकलन समय पर भी की जा सकती है, मशीन से उत्पन्न कोड को रेपो के लिए प्रतिबद्ध होने से बचाकर। सामान्य तौर पर, किसी भी प्रकार का यादगार गणितीय कार्य संकलन समय कार्यों के साथ पूर्व-निर्मित लुकअप तालिकाओं के लिए एक अच्छा फिट है।

अधिक अनुमान के अनुसार, कोई भी चाहता है, उदाहरण के लिए, एक प्रामाणिक स्रोत से प्रोटोबफ परिभाषा डाउनलोड करें और संकलन समय पर प्रकार बनाने के लिए इसका उपयोग करें। लेकिन हो सकता है कि संकलन समय पर करने की अनुमति बहुत अधिक हो?

मुझे लगता है कि संकलन समय के कार्य एक ही समय में बहुत शक्तिशाली और बहुत कमजोर होते हैं: वे बहुत लचीले होते हैं और अजीब तरीकों से त्रुटि कर सकते हैं/सी ++ टेम्पलेट्स के तरीके को धीमा कर सकते हैं, लेकिन दूसरी तरफ वे बहुत स्थिर और मुश्किल हैं प्रथम श्रेणी के कार्यों जैसी चीजों के अनुकूल।

दूसरे भाग के लिए, मुझे ऐसा कोई तरीका नहीं दिख रहा है जिससे आप "फ़ंक्शन का टुकड़ा जो किसी विशेष प्रकार के स्लाइस को संसाधित करते हैं और एक तत्व लौटाते हैं" जैसा कुछ बना सकते हैं, या एक एड-हॉक सिंटैक्स []func<T>([]T) T में, जो अनिवार्य रूप से हर सांख्यिकीय रूप से टाइप की गई कार्यात्मक भाषा में करना बहुत आसान है। वास्तव में जरूरत इस बात की है कि मान पैरामीट्रिक प्रकारों को लेने में सक्षम हों, न कि कुछ स्रोत-कोड स्तर कोड पीढ़ी।

@ बन्सिम

दूसरे भाग के लिए, मुझे ऐसा कोई तरीका नहीं दिख रहा है जिससे आप "फ़ंक्शन का टुकड़ा जो किसी विशेष प्रकार के स्लाइस को संसाधित करते हैं और एक तत्व लौटाते हैं" जैसा कुछ बना सकते हैं,

यदि आप एक प्रकार के पैरामीटर के बारे में बात कर रहे हैं, तो मेरे प्रस्ताव में लिखा जाएगा:

const func SliceOfSelectors(T gotype) gotype { return []func([]T)T (type) }

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

हाँ, लेकिन मेरी राय में उस तरह की चीज़ जिसके लिए बॉक्सिंग की आवश्यकता होती है, उसे टाइप-सेफ्टी रखते हुए अनुमति दी जानी चाहिए, शायद विशेष सिंटैक्स के साथ जो "बॉक्सिंगनेस" को इंगित करता है। "जेनेरिक" जोड़ने का एक बड़ा हिस्सा वास्तव में interface{} की टाइप-असुरक्षा से बचने के लिए है, भले ही interface{} का ओवरहेड टालने योग्य न हो। (शायद केवल कुछ पैरामीट्रिक प्रकार के निर्माण को पॉइंटर और इंटरफ़ेस प्रकारों के साथ अनुमति दें जो "पहले से ही" बॉक्सिंग हैं? जावा की Integer आदि बॉक्सिंग ऑब्जेक्ट पूरी तरह से एक बुरा विचार नहीं हैं, हालांकि मूल्य प्रकारों के स्लाइस मुश्किल हैं)

मुझे ऐसा लगता है कि संकलन-समय के कार्य बहुत सी ++ की तरह हैं, और मेरे जैसे लोगों के लिए बेहद निराशाजनक होगा, जो गो 2 की अपेक्षा करते हैं कि एक आधुनिक पैरामीट्रिक प्रकार प्रणाली है जो एक ध्वनि प्रकार सिद्धांत में आधारित है, न कि स्रोत कोड के टुकड़ों में हेरफेर करने के आधार पर हैक। जेनरिक के बिना भाषा में।

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

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

@ बन्सिम

"जेनेरिक" जोड़ने का एक बड़ा हिस्सा वास्तव में इंटरफ़ेस की प्रकार-असुरक्षितता से बचने के लिए है {} तब भी जब इंटरफ़ेस का ओवरहेड {} परिहार्य नहीं है।

"परिहार्य नहीं" सापेक्ष है। ध्यान दें कि बॉक्सिंग का ओवरहेड 2009 से रस की पोस्ट में #3 बिंदु है (https://research.swtch.com/generic)।

उम्मीद है कि Go2 में एक आधुनिक पैरामीट्रिक प्रकार की प्रणाली होगी जो स्रोत कोड के टुकड़ों में हेरफेर के आधार पर हैक के बजाय ध्वनि प्रकार सिद्धांत पर आधारित होगी।

एक अच्छा "ध्वनि प्रकार सिद्धांत" वर्णनात्मक है, निर्देशात्मक नहीं। मेरा प्रस्ताव विशेष रूप से दूसरे क्रम के लैम्ब्डा कैलकुलस (सिस्टम एफ की तर्ज पर) से आकर्षित होता है, जहां gotype अर्थ type है और पूरे प्रथम-क्रम प्रकार की प्रणाली को दूसरे में फहराया जाता है -ऑर्डर ("संकलन-समय") प्रकार।

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

यह सच है कि मेरे प्रस्ताव में अंतर्निहित प्रकार सिद्धांत अकादमिक साहित्य की तुलना में कम औपचारिक रूप से निर्दिष्ट है, लेकिन इसका मतलब यह नहीं है कि यह वहां नहीं है।

@andrewcmyers

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

गो टुडे में यह पहले से ही सच है: यदि आप ध्यान से देखें, तो आप ध्यान देंगे कि किसी दिए गए गो पैकेज के लिए कंपाइलर द्वारा जेनरेट की गई ऑब्जेक्ट फाइलों में ट्रांजिटिव निर्भरता के उन हिस्सों की जानकारी शामिल होती है जो निर्यात किए गए एपीआई को प्रभावित करते हैं।

मॉड्यूल सिस्टम द्वारा प्रदान किया गया ढीला युग्मन कमजोर हो जाएगा, और सॉफ्टवेयर अधिक भंगुर हो जाएगा।

मैंने सुना है कि गो एपीआई में ठोस प्रकारों के बजाय interface प्रकार के निर्यात के लिए वकालत करने के लिए एक ही तर्क का उपयोग किया जाता है, और रिवर्स अधिक सामान्य हो जाता है: समयपूर्व अमूर्तता एपीआई के प्रकार और बाधा के विस्तार को रोकता है। (ऐसे एक उदाहरण के लिए, #19584 देखें।) यदि आप तर्क की इस पंक्ति पर भरोसा करना चाहते हैं तो मुझे लगता है कि आपको कुछ ठोस उदाहरण प्रदान करने की आवश्यकता है।

यह सी ++ टेम्पलेट्स के साथ समस्याओं में से एक है।

जैसा कि मैंने इसे देखा, सी ++ टेम्पलेट्स के साथ मुख्य समस्याएं हैं (किसी विशेष क्रम में नहीं):

• अत्यधिक वाक्यात्मक अस्पष्टता।
  ए। प्रकार के नाम और मूल्य नामों के बीच अस्पष्टता।
  बी। ऑपरेटर ओवरलोडिंग के लिए अत्यधिक व्यापक समर्थन, जिससे ऑपरेटर के उपयोग से बाधाओं का अनुमान लगाने की क्षमता कमजोर हो जाती है।
• मेटाप्रोग्रामिंग (या, समकक्ष, मेटाप्रोग्रामिंग समर्थन के तदर्थ विकास) के लिए अधिभार संकल्प पर अधिक निर्भरता।
  ए। विशेष रूप से wrt संदर्भ-ढहने वाले नियम।
• SFINAE सिद्धांत का व्यापक रूप से व्यापक अनुप्रयोग, जिसके कारण बहुत कठिन-से-प्रसार बाधाएं और टाइप परिभाषाओं में बहुत अधिक निहित शर्तें हैं, जिससे बहुत कठिन त्रुटि रिपोर्टिंग होती है।
• एएसटी सबस्टेशन और उच्च-क्रम संकलन कलाकृतियों के बजाय टोकन-पेस्टिंग और टेक्स्टुअल इंक्लूजन (सी प्रीप्रोसेसर) का अति प्रयोग (जो शुक्र है कि मॉड्यूल के साथ कम से कम आंशिक रूप से संबोधित किया जाता है)।
• C++ कंपाइलरों के लिए अच्छी बूटस्ट्रैपिंग भाषाओं की कमी, लंबे समय तक रहने वाले कंपाइलर वंशों (जैसे GCC टूलचेन) में खराब त्रुटि-रिपोर्टिंग की ओर ले जाती है।
• अलग-अलग नामित "अवधारणाओं" पर ऑपरेटरों के मैपिंग सेट से उत्पन्न नामों का दोहरीकरण (और कभी-कभी गुणा) (ऑपरेटरों को खुद को मौलिक बाधाओं के रूप में मानने के बजाय)।

मैं एक दशक से सी ++ में कोडिंग कर रहा हूं और मुझे सी ++ की कमियों की लंबाई पर चर्चा करने में खुशी हो रही है, लेकिन तथ्य यह है कि प्रोग्राम निर्भरताएं ट्रांजिटिव हैं, मेरी शिकायतों की सूची के शीर्ष पर कभी भी दूरस्थ रूप से नहीं रही है।

दूसरी ओर, मॉड्यूल ए में एक प्रकार में एक विधि जोड़ने के लिए ओ (एन) निर्भरताओं की एक श्रृंखला को अद्यतन करने की आवश्यकता है और इसे मॉड्यूल डी में उपयोग करने में सक्षम होना चाहिए? यही वह समस्या है जो मुझे नियमित आधार पर धीमा कर देती है। जहां पैरामीट्रिकिटी और लूज कपलिंग में विरोध होता है, मैं किसी भी दिन पैरामीट्रिकिटी चुनूंगा।

फिर भी, मैं दृढ़ता से मानता हूं कि मेटाप्रोग्रामिंग और पैरामीट्रिक बहुरूपता को अलग किया जाना चाहिए, और सी ++ का भ्रम उनमें से मूल कारण है कि सी ++ टेम्पलेट परेशान क्यों हैं। सीधे शब्दों में कहें, सी ++ स्टेरॉयड पर अनिवार्य रूप से मैक्रोज़ का उपयोग करके एक प्रकार-सिद्धांत विचार को लागू करने का प्रयास करता है, जो बहुत ही समस्याग्रस्त है क्योंकि प्रोग्रामर टेम्पलेट्स को वास्तविक पैरामीट्रिक बहुरूपता के रूप में सोचना पसंद करते हैं और अप्रत्याशित व्यवहार से प्रभावित होते हैं। कंपाइल-टाइम फ़ंक्शंस मेटाप्रोग्रामिंग और हैक को बदलने के लिए एक अच्छा विचार है जो go generate है, लेकिन मुझे विश्वास नहीं है कि यह सामान्य प्रोग्रामिंग करने का धन्य तरीका होना चाहिए।

"असली" पैरामीट्रिक बहुरूपता ढीले युग्मन में मदद करता है और इसके साथ संघर्ष नहीं करना चाहिए। इसे बाकी प्रकार की प्रणाली के साथ भी कसकर एकीकृत किया जाना चाहिए; उदाहरण के लिए इसे शायद वर्तमान इंटरफ़ेस सिस्टम में एकीकृत किया जाना चाहिए, ताकि इंटरफ़ेस प्रकारों के कई उपयोगों को फिर से लिखा जा सके जैसे:

func <T io.Reader> ReadAll(in T)

जो इंटरफ़ेस ओवरहेड (जैसे जंग के उपयोग) से बचना चाहिए, हालांकि इस मामले में यह बहुत उपयोगी नहीं है।

एक बेहतर उदाहरण sort पैकेज हो सकता है, जहां आपके पास कुछ ऐसा हो सकता है

func <T Comparable> Sort(slice []T)

जहां Comparable बस एक अच्छा पुराना इंटरफ़ेस है जिसे प्रकार लागू कर सकते हैं। Sort को तब मूल्य प्रकारों के एक स्लाइस पर बुलाया जा सकता है जो Comparable को लागू करते हैं, उन्हें इंटरफ़ेस प्रकारों में बॉक्स किए बिना।

@bcmills टाइप सिस्टम द्वारा अप्रतिबंधित ट्रांजिटिव निर्भरताएं, मेरे विचार में, सी ++ के बारे में आपकी कुछ शिकायतों के मूल में हैं। यदि आप मॉड्यूल ए, बी, सी और डी को नियंत्रित करते हैं तो ट्रांजिटिव निर्भरता इतनी अधिक समस्या नहीं है। सामान्य तौर पर, आप मॉड्यूल ए विकसित कर रहे हैं और केवल कमजोर रूप से जानते हैं कि मॉड्यूल डी नीचे है, और इसके विपरीत, डी के डेवलपर ए से अनजान हो सकता है। यदि मॉड्यूल डी अब, डी में दिखाई देने वाली घोषणाओं में कोई बदलाव किए बिना, किसी प्रकार के पैरामीटर पर कुछ नए ऑपरेटर का उपयोग करना शुरू कर देता है- या केवल उस प्रकार के पैरामीटर का उपयोग एक नए मॉड्यूल ई के लिए एक प्रकार के तर्क के रूप में करता है। निहित बाधाएं - वे बाधाएं सभी ग्राहकों तक पहुंच जाएंगी, जो बाधाओं को संतुष्ट करने वाले प्रकार के तर्कों का उपयोग नहीं कर रहे हैं। डेवलपर डी को कुछ भी नहीं बताता है कि वे इसे उड़ा रहे हैं। असल में, आपके पास एक प्रकार का वैश्विक प्रकार का अनुमान है, जिसमें डिबगिंग की सभी कठिनाइयों को शामिल किया गया है।

मेरा मानना ​​है कि हमने जीनस [ पीएलडीआई'15 ] में जो दृष्टिकोण अपनाया वह काफी बेहतर है। टाइप पैरामीटर में स्पष्ट, लेकिन हल्के, बाधाएं हैं (मैं ऑपरेशन बाधाओं का समर्थन करने के बारे में आपकी बात लेता हूं; सीएलयू ने दिखाया कि 1977 में इसे सही तरीके से कैसे किया जाए)। जीनस प्रकार की जाँच पूरी तरह से मॉड्यूलर है। सामान्य कोड या तो कोड स्थान को अनुकूलित करने के लिए केवल एक बार संकलित किया जा सकता है या अच्छे प्रदर्शन के लिए विशेष प्रकार के तर्कों के लिए विशेषीकृत किया जा सकता है।

@andrewcmyers

यदि मॉड्यूल डी अब, डी में दिखाई देने वाली घोषणाओं में कोई बदलाव किए बिना, टाइप पैरामीटर पर कुछ नए ऑपरेटर का उपयोग करना शुरू कर देता है [...] [क्लाइंट] बाधाओं को संतुष्ट करने वाले प्रकार के तर्कों का उपयोग नहीं कर रहे हैं। डेवलपर डी को कुछ भी नहीं बताता है कि वे इसे उड़ा रहे हैं।

निश्चित रूप से, लेकिन यह किसी भी सामान्य प्रोग्रामिंग तंत्र से स्वतंत्र गो में निहित बाधाओं के लिए पहले से ही सच है।

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

इसी तरह, गो टाइप सिस्टम आज परिवर्तनीय जीवनकाल पर बाधाओं को निर्दिष्ट नहीं करता है: io.Writer के कुछ कार्यान्वयन गलती से मानते हैं कि वे पास-इन स्लाइस का संदर्भ रख सकते हैं और बाद में इसे पढ़ सकते हैं (उदाहरण के लिए वास्तविक लेखन को अतुल्यकालिक रूप से करके) बैकग्राउंड गोरौटाइन में), लेकिन यह डेटा दौड़ का कारण बनता है यदि Write का कॉलर बाद के Write के लिए उसी बैकिंग स्लाइस का पुन: उपयोग करने का प्रयास करता है।

या एक प्रकार-स्विच का उपयोग करने वाला फ़ंक्शन स्विच में किसी एक प्रकार में एक विधि का एक अलग पथ ले सकता है।

या किसी विशेष त्रुटि कोड के लिए जाँच करने वाला फ़ंक्शन टूट सकता है यदि त्रुटि उत्पन्न करने वाला फ़ंक्शन उस स्थिति की रिपोर्ट करने के तरीके को बदल देता है। (उदाहरण के लिए, https://github.com/golang/go/issues/19647 देखें।)

या किसी विशेष त्रुटि प्रकार के लिए जाँच करने वाला फ़ंक्शन टूट सकता है यदि त्रुटि के चारों ओर रैपर जोड़े या निकाले जाते हैं (जैसा कि Go 1.5 में मानक net पैकेज में हुआ था)।

या एक एपीआई में उजागर चैनल पर बफरिंग बदल सकती है, गतिरोध और/या दौड़ शुरू कर सकती है।

...और इसी तरह।

इस संबंध में गो असामान्य नहीं है: वास्तविक दुनिया के कार्यक्रमों में निहित बाधाएं सर्वव्यापी हैं।

यदि आप स्पष्ट टिप्पणियों में सभी प्रासंगिक बाधाओं को पकड़ने का प्रयास करते हैं, तो आप दो दिशाओं में से एक में जा रहे हैं।

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

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

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

@bcmills क्या आप उत्तम को अच्छे का दुश्मन नहीं बना रहे हैं? हां, ऐसी अंतर्निहित बाधाएं हैं जिन्हें एक प्रकार की प्रणाली में पकड़ना मुश्किल है। (और अच्छा मॉड्यूलर डिज़ाइन संभव होने पर इस तरह की अंतर्निहित बाधाओं को पेश करने से बचता है।) एक व्यापक विश्लेषण होना बहुत अच्छा होगा जो आपके द्वारा जाँच की जाने वाली सभी संपत्तियों की सांख्यिकीय रूप से जाँच कर सकता है - और प्रोग्रामर को स्पष्ट, गैर-भ्रामक स्पष्टीकरण प्रदान करता है कि वे कहाँ हैं गलतियाँ कर रहे हैं। स्वचालित त्रुटि निदान और स्थानीयकरण पर हाल की प्रगति के साथ भी, मैं अपनी सांस नहीं रोक रहा हूं। एक बात के लिए, विश्लेषण उपकरण केवल आपके द्वारा दिए गए कोड का विश्लेषण कर सकते हैं। डेवलपर्स के पास हमेशा उन सभी कोड तक पहुंच नहीं होती है जो उनके साथ लिंक हो सकते हैं।

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

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

मैं ध्यान देता हूं कि अन्य निहित बाधाओं के आपके कुछ उदाहरणों में त्रुटि प्रबंधन शामिल है। मुझे लगता है कि अपवादों की हमारी हल्की स्थिर जाँच [ PLDI 2016 ] इन उदाहरणों को संबोधित करेगी।

@andrewcmyers

तो जहां ऐसी बाधाएं हैं जिन्हें एक प्रकार की प्रणाली में पकड़ना आसान है, क्यों न प्रोग्रामर को उन्हें लिखने की क्षमता दें?
[…]
एक बार जब आप बड़े सॉफ़्टवेयर का निर्माण शुरू कर देते हैं जो सॉफ़्टवेयर मॉड्यूल को परत करता है, तो आप वैसे भी इस तरह की अंतर्निहित बाधाओं को समझाते हुए टिप्पणियां लिखना शुरू कर देते हैं। मान लें कि उन्हें व्यक्त करने का एक अच्छा, जांच योग्य तरीका है, तो क्यों न संकलक को मजाक में आने दें ताकि यह आपकी मदद कर सके?

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

लेकिन मैं उस तर्क को एक कदम आगे ले जाऊंगा: बातचीत भी होती है! यदि आपको बाधा के लिए टिप्पणी लिखने की आवश्यकता नहीं है (क्योंकि यह उन मनुष्यों के संदर्भ में स्पष्ट है जो कोड के साथ काम करते हैं), तो आपको संकलक के लिए वह टिप्पणी लिखने की आवश्यकता क्यों है? मेरी व्यक्तिगत प्राथमिकताओं के बावजूद, गो का कचरा-संग्रह और शून्य-मूल्यों का उपयोग स्पष्ट रूप से "प्रोग्रामर को स्पष्ट आविष्कारों की आवश्यकता नहीं है" की ओर एक पूर्वाग्रह का संकेत देता है। ऐसा हो सकता है कि जीनस-शैली की मॉडलिंग टिप्पणियों में व्यक्त की जाने वाली कई बाधाओं को व्यक्त कर सकती है, लेकिन यह उन बाधाओं को दूर करने के मामले में कैसा है जो टिप्पणियों में भी समाप्त हो जाएंगी?

मुझे ऐसा लगता है कि जीनस-शैली के मॉडल वैसे भी टिप्पणियों से कहीं अधिक हैं: वे वास्तव में कुछ मामलों में कोड के शब्दार्थ को बदलते हैं, वे इसे बाधित नहीं करते हैं। अब हमारे पास दो अलग-अलग तंत्र होंगे - इंटरफेस और टाइप-मॉडल - व्यवहार को मानकीकृत करने के लिए। यह गो भाषा में एक प्रमुख बदलाव का प्रतिनिधित्व करेगा: हमने समय के साथ इंटरफेस के लिए कुछ सर्वोत्तम प्रथाओं की खोज की है (जैसे कि "उपभोक्ता पक्ष पर इंटरफेस परिभाषित करें") और यह स्पष्ट नहीं है कि यह अनुभव इस तरह की मौलिक रूप से भिन्न प्रणाली में अनुवाद करेगा, यहां तक ​​​​कि गो 1 संगतता की उपेक्षा करना।

इसके अलावा, गो के उत्कृष्ट गुणों में से एक यह है कि इसके विनिर्देश को दोपहर में पढ़ा जा सकता है (और काफी हद तक समझा जा सकता है)। यह मेरे लिए स्पष्ट नहीं है कि गो भाषा में बाधाओं की एक जीनस-शैली प्रणाली को इसे काफी जटिल किए बिना जोड़ा जा सकता है - मैं कल्पना में बदलाव के लिए एक ठोस प्रस्ताव देखने के लिए उत्सुक हूं।

यहां "मेटाप्रोग्रामिंग" के लिए एक दिलचस्प डेटा बिंदु है। sync और atomic पैकेज में कुछ प्रकारों के लिए यह अच्छा होगा - अर्थात्, atomic.Value और sync.Map - CompareAndSwap विधियों का समर्थन करने के लिए, लेकिन वे केवल उन प्रकारों के लिए काम करते हैं जो तुलनीय होते हैं। शेष atomic.Value और sync.Map एपीआई उन तरीकों के बिना उपयोगी रहते हैं, इसलिए उस उपयोग-मामले के लिए हमें या तो SFINAE (या अन्य प्रकार के सशर्त-परिभाषित एपीआई) की आवश्यकता होती है या गिरना पड़ता है प्रकार के अधिक जटिल पदानुक्रम पर वापस।

मैं आदिवासी सिलेबिक्स का उपयोग करने के इस रचनात्मक वाक्यविन्यास विचार को छोड़ना चाहता हूं।

@bcmills क्या आप इन तीन बिंदुओं के बारे में अधिक बता सकते हैं?

1. प्रकार के नाम और मूल्य नामों के बीच अस्पष्टता।
2. ऑपरेटर ओवरलोडिंग के लिए अत्यधिक व्यापक समर्थन
   3. मेटाप्रोग्रामिंग के लिए अधिभार संकल्प पर अधिक निर्भरता

@mahdix ज़रूर।

1. प्रकार के नाम और मूल्य नामों के बीच अस्पष्टता।

यह लेख एक अच्छा परिचय देता है। सी ++ प्रोग्राम को पार्स करने के लिए, आपको पता होना चाहिए कि कौन से नाम प्रकार हैं और कौन से मूल्य हैं। जब आप एक टेम्प्लेटेड C++ प्रोग्राम को पार्स करते हैं, तो आपके पास टेम्प्लेट पैरामीटर के सदस्यों के लिए वह जानकारी उपलब्ध नहीं होती है।

गो फॉर कंपोजिट लिटरल में एक समान समस्या उत्पन्न होती है, लेकिन अस्पष्टता मूल्यों और प्रकारों के बजाय मूल्यों और फ़ील्ड नामों के बीच होती है। इस गो कोड में:

const a = someValue
x := T{a: b}

क्या a एक शाब्दिक फ़ील्ड नाम है, या यह निरंतर a मानचित्र कुंजी या सरणी अनुक्रमणिका के रूप में उपयोग किया जा रहा है?

1. ऑपरेटर ओवरलोडिंग के लिए अत्यधिक व्यापक समर्थन

तर्क-निर्भर लुकअप शुरू करने के लिए एक अच्छी जगह है। सी ++ में ऑपरेटरों का अधिभार रिसीवर प्रकार पर विधियों के रूप में या कई नामस्थानों में मुफ्त कार्यों के रूप में हो सकता है, और उन अधिभारों को हल करने के नियम काफी जटिल हैं।

उस जटिलता से बचने के कई तरीके हैं, लेकिन सबसे सरल (जैसा कि वर्तमान में गो करता है) ऑपरेटर को पूरी तरह से ओवरलोडिंग की अनुमति देना है।

1. मेटाप्रोग्रामिंग के लिए अधिभार संकल्प पर अधिक निर्भरता

<type_traits> लाइब्रेरी शुरू करने के लिए एक अच्छी जगह है। यह देखने के लिए कि ओवरलोड रिज़ॉल्यूशन कैसे काम करता है, अपने अनुकूल पड़ोस libc++ में कार्यान्वयन देखें।

यदि गो कभी भी मेटाप्रोग्रामिंग का समर्थन करता है (और यहां तक ​​​​कि यह बहुत ही संदिग्ध है), तो मैं सशर्त परिभाषाओं की रक्षा के लिए मौलिक संचालन के रूप में अधिभार संकल्प को शामिल करने की उम्मीद नहीं करता।

@बीसीमिल्स
जैसा कि मैंने कभी सी ++ का उपयोग नहीं किया है, क्या आप कुछ प्रकाश डाल सकते हैं जहां पूर्वनिर्धारित 'इंटरफेस' को लागू करने के माध्यम से ऑपरेटर ओवरलोडिंग जटिलता के संदर्भ में खड़ा है। पायथन और कोटलिन इसके उदाहरण हैं।

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

यह प्रस्ताव टेम्प्लेट पर आधारित है, मैक्रो विस्तार के लिए एक प्रणाली पर्याप्त नहीं होगी? मैं go generate या gotemplate जैसी परियोजनाओं के बारे में बात नहीं कर रहा हूँ। मैं इस तरह और अधिक के बारे में बात कर रहा हूँ:

macro MacroFoo(stmt ast.Statement) {
    ....
}

मैक्रो बॉयलरप्लेट और प्रतिबिंब के उपयोग को कम कर सकता है।

मुझे लगता है कि सी ++ एक अच्छा पर्याप्त उदाहरण है कि जेनेरिक टेम्पलेट्स या मैक्रोज़ पर आधारित नहीं होना चाहिए। विशेष रूप से गो पर विचार करने वाले अज्ञात कार्यों की तरह सामान हैं जिन्हें वास्तव में अनुकूलन के अलावा संकलन-समय पर "तत्काल" नहीं किया जा सकता है।

@ समदादी आप "आप लोगों के साथ क्या गलत है" कहे बिना अपनी बात रख सकते हैं। ऐसा कहने के बाद, जटिलता का तर्क पहले भी कई बार उठाया जा चुका है।

गो पैरामीट्रिक बहुरूपता (जेनेरिक) के समर्थन को छोड़ कर सरलता हासिल करने की कोशिश करने वाली पहली भाषा नहीं है, इसके बावजूद कि यह सुविधा पिछले 40 वर्षों में तेजी से महत्वपूर्ण होती जा रही है - मेरे अनुभव में, यह दूसरे सेमेस्टर प्रोग्रामिंग पाठ्यक्रमों का एक प्रमुख है।

भाषा में सुविधा न होने की समस्या यह है कि प्रोग्रामर अंत में ऐसे वर्कअराउंड का सहारा लेते हैं जो और भी बदतर हैं। उदाहरण के लिए, गो प्रोग्रामर अक्सर कोड टेम्प्लेट लिखते हैं जो विभिन्न वांछित प्रकारों के लिए "वास्तविक" कोड बनाने के लिए मैक्रो-विस्तारित होते हैं। लेकिन असली प्रोग्रामिंग भाषा वह है जिसे आप टाइप करते हैं, न कि वह जिसे कंपाइलर देखता है। तो इस रणनीति का प्रभावी ढंग से मतलब है कि आप एक (अब मानक नहीं) भाषा का उपयोग कर रहे हैं जिसमें सी ++ टेम्पलेट्स की सभी भंगुरता और कोड ब्लोट है।

जैसा कि https://blog.golang.org/toward-go2 पर बताया गया है, हमें "अनुभव रिपोर्ट" प्रदान करने की आवश्यकता है, ताकि आवश्यकता और डिज़ाइन लक्ष्यों को निर्धारित किया जा सके। क्या आप कुछ मिनट ले सकते हैं और आपके द्वारा देखे गए मैक्रो मामलों का दस्तावेजीकरण कर सकते हैं?

कृपया इस बग को विषय और नागरिक पर रखें। और फिर, https://golang.org/wiki/NoMeToo। कृपया केवल तभी टिप्पणी करें जब आपके पास जोड़ने के लिए अद्वितीय और रचनात्मक जानकारी हो।

@mandolyte जेनेरिक के लिए एक (आंशिक) विकल्प के रूप में कोड जनरेशन की वकालत करने वाले वेब पर विस्तृत स्पष्टीकरण खोजना बहुत आसान है:
https://appliedgo.net/generics/
https://www.calhoun.io/using-code-generation-to-survive-without-generics-in-go/
http://blog.ralch.com/tutorial/golang-code-generation-and-generics/

स्पष्ट रूप से वहाँ बहुत सारे लोग हैं जो इस दृष्टिकोण को अपना रहे हैं।

@andrewcmyers , कोड जनरेशन BUT का उपयोग करते समय कुछ सीमाएँ और साथ ही सुविधा चेतावनी भी हैं।
आम तौर पर - यदि आप मानते हैं कि यह दृष्टिकोण सबसे अच्छा/काफी अच्छा है, तो मुझे लगता है कि गो टूल चेन के भीतर से कुछ इसी तरह की पीढ़ी को अनुमति देने का प्रयास एक आशीर्वाद होगा।

• इस मामले में संकलक अनुकूलन एक चुनौती हो सकती है, लेकिन रनटाइम सुसंगत होगा, और कोड रखरखाव, उपयोगकर्ता अनुभव (सरलता...), मानक सर्वोत्तम अभ्यास और एकीकृत कोड मानकों को रखा जा सकता है।
  इसके अलावा - डिबगिंग टूल (प्रोफाइलर, स्टेप डिबगर्स आदि) के अलावा सभी टूल चेन को समान रखा जाएगा, जिसमें कोड की लाइनें दिखाई देंगी जो डेवलपर द्वारा नहीं लिखी गई थीं, लेकिन यह डिबगिंग के दौरान ASM कोड में कदम रखने जैसा है - केवल इसका एक पठनीय कोड :)।

डाउनसाइड - गो टूल चेन के अंदर इस दृष्टिकोण के लिए कोई मिसाल नहीं (जिसे मैं जानता हूं)।

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

IMHO: यह कम कीमत के साथ आसानी से हासिल किया गया समझौता है।

स्पष्ट होने के लिए, मैं मैक्रो-स्टाइल कोड जनरेशन पर विचार नहीं करता, चाहे वह gen, cpp, gofmt -r, या अन्य मैक्रो/टेम्पलेट टूल्स के साथ किया गया हो, जेनेरिक समस्या का एक अच्छा समाधान होने के लिए, भले ही मानकीकृत हो। इसमें सी ++ टेम्प्लेट जैसी ही समस्याएं हैं: कोड ब्लोट, मॉड्यूलर टाइप चेकिंग की कमी और डिबगिंग में कठिनाई। जैसे ही आप शुरू करते हैं, यह और भी खराब हो जाता है, जैसा कि स्वाभाविक है, अन्य सामान्य कोड के संदर्भ में सामान्य कोड बनाना। मेरे दिमाग में, फायदे सीमित हैं: यह गो कंपाइलर लेखकों के लिए जीवन को अपेक्षाकृत सरल बनाए रखेगा और यह कुशल कोड उत्पन्न करता है - जब तक कि निर्देश कैश दबाव न हो, आधुनिक सॉफ़्टवेयर में लगातार स्थिति!

मुझे लगता है कि बिंदु यह था कि कोड जनरेशन का उपयोग स्थानापन्न करने के लिए किया जाता है
जेनरिक, इसलिए जेनरिक को उन अधिकांश उपयोग मामलों को हल करना चाहिए।

बुधवार को 26 जुलाई, 2017, 22:41 एंड्रयू मायर्स, नोटिफिकेशन @github.com ने लिखा:

स्पष्ट होने के लिए, मैं मैक्रो-शैली कोड पीढ़ी पर विचार नहीं करता, चाहे किया गया हो
gen, cpp, gofmt -r, या अन्य मैक्रो/टेम्पलेट टूल के साथ, एक अच्छा होने के लिए
मानकीकृत होने पर भी जेनरिक समस्या का समाधान। इसमें वही है
सी ++ टेम्प्लेट के रूप में समस्याएं: कोड ब्लोट, मॉड्यूलर टाइप चेकिंग की कमी, और
डिबगिंग में कठिनाई। जैसे ही आप शुरू करते हैं, यह खराब हो जाता है, जैसा कि स्वाभाविक है, निर्माण
अन्य सामान्य कोड के संदर्भ में सामान्य कोड। मेरे विचार से, फायदे हैं
सीमित: यह गो कंपाइलर लेखकों के लिए जीवन को अपेक्षाकृत सरल बनाए रखेगा
और यह कुशल कोड उत्पन्न करता है - जब तक कि निर्देश कैश न हो
दबाव, आधुनिक सॉफ्टवेयर में लगातार स्थिति!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-318242016 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
.

इसमें कोई संदेह नहीं है कि कोड जनरेशन एक वास्तविक समाधान नहीं है, भले ही भाषा के समर्थन में कुछ के साथ लिपटा हुआ हो और "भाषा का हिस्सा" के रूप में देखने और महसूस करने के लिए।

मेरा कहना था कि यह बहुत ही लागत प्रभावी था।

बीटीडब्ल्यू, यदि आप कुछ कोड पीढ़ी के विकल्प देखते हैं, तो आप आसानी से देख सकते हैं कि वे कैसे अधिक पठनीय, तेज़ हो सकते थे, और कुछ गलत अवधारणाओं की कमी हो सकती थी (उदाहरण के लिए पॉइंटर्स बनाम मानों के सरणी पर पुनरावृत्ति) भाषा ने उन्हें बेहतर उपकरण दिए थे इसके लिए।

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

@bcmills और @ianlancetaylor द्वारा जेनेरिक प्रस्तावों को पढ़ने के बाद, मैंने निम्नलिखित अवलोकन किए हैं:

संकलन-समय के कार्य और प्रथम श्रेणी के प्रकार

मुझे संकलन-समय मूल्यांकन का विचार पसंद है, लेकिन मुझे इसे शुद्ध कार्यों तक सीमित करने का लाभ नहीं दिख रहा है। यह प्रस्ताव बिल्टिन gotype का परिचय देता है, लेकिन इसके उपयोग को कॉन्स्ट फ़ंक्शन और फ़ंक्शन स्कोप के भीतर परिभाषित किसी भी डेटा प्रकार तक सीमित करता है। एक पुस्तकालय उपयोगकर्ता के दृष्टिकोण से, तात्कालिकता "नया" जैसे निर्माण कार्यों तक सीमित है, और इस तरह के कार्य हस्ताक्षर की ओर जाता है:

const func New(K, V gotype, hashfn Hashfn(K), eqfn Eqfn(K)) func()*Hashmap(K, V, hashfn, eqfn)

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

Go . में पैरामीटर टाइप करें

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

"टाइप चेकर" खंड के तहत, प्रस्ताव प्रक्रिया को गति देने के लिए कुछ उपयोगी प्रकार के प्रतिबंधों को भी सूचीबद्ध करता है, जैसे "इंडेक्सेबल", "तुलनीय", "कॉल करने योग्य", "समग्र", आदि ... जो मुझे समझ में नहीं आता है वह है उपयोगकर्ता को अपने स्वयं के प्रकार के प्रतिबंध निर्दिष्ट करने की अनुमति क्यों नहीं देते? प्रस्ताव में कहा गया है कि

पैरामीटरयुक्त फ़ंक्शन में पैरामीटरयुक्त प्रकारों का उपयोग कैसे किया जा सकता है, इस पर कोई प्रतिबंध नहीं है।

हालांकि, अगर पहचानकर्ताओं के पास अधिक बाधाएं थीं, तो क्या इसका संकलक की सहायता करने का असर नहीं होगा? विचार करना:

HashMap[Anything,Anything] // Compiler must always compare the implementation and usages to make sure this is valid.

बनाम

HashMap[Comparable,Anything] // Compiler can first filter out instantiations for incomparable types before running an exhaustive check.

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

@smasher164

मुझे संकलन-समय मूल्यांकन का विचार पसंद है, लेकिन मुझे इसे शुद्ध कार्यों तक सीमित करने का लाभ नहीं दिख रहा है।

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

@smasher164

जो मुझे समझ में नहीं आता है वह यह है कि उपयोगकर्ता को अपने स्वयं के प्रकार के प्रतिबंध निर्दिष्ट करने की अनुमति क्यों नहीं दी जाती है?

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

यदि पहचानकर्ताओं के पास और अधिक बाधाएँ थीं, तो क्या इसका संकलक की सहायता करने का प्रभाव नहीं होगा?

भाषा को उसके उपयोगकर्ताओं के लिए डिज़ाइन किया जाना चाहिए, न कि संकलक-लेखकों के लिए।

विवश प्रकारों के लिए अतिरिक्त सिंटैक्स निर्दिष्ट करने की कोई आवश्यकता नहीं है क्योंकि सभी वाक्यात्मक बाधाओं का उपयोग से अनुमान लगाया जा सकता है।

यह मार्ग C++ नीचे चला गया। प्रासंगिक उपयोगों की पहचान करने के लिए इसे वैश्विक कार्यक्रम विश्लेषण की आवश्यकता है। प्रोग्रामर द्वारा मॉड्यूलर फैशन में कोड के बारे में तर्क नहीं किया जा सकता है, और त्रुटि संदेश वर्बोज़ और समझ से बाहर हैं।

आवश्यक संचालन निर्दिष्ट करना इतना आसान और हल्का हो सकता है। उदाहरण के लिए सीएलयू (1977) देखें।

@andrewcmyers

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

वह "मॉड्यूलर" की एक विशेष परिभाषा का उपयोग कर रहा है, जो मुझे नहीं लगता कि यह उतना ही सार्वभौमिक है जितना आप मानते हैं। 2013 के प्रस्ताव के तहत, प्रत्येक फ़ंक्शन या प्रकार में आयातित पैकेजों से अनुमानित बाधाओं का एक स्पष्ट सेट होगा, ठीक उसी तरह जैसे गैर-पैरामीट्रिक फ़ंक्शंस के रन-टाइम (और रन-टाइम बाधाएं) नीचे से प्राप्त होते हैं- कॉल चेन से आज ऊपर।

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

और त्रुटि संदेश वर्बोज़ और समझ से बाहर हैं।

हमारे पास कुछ उदाहरण हैं (जीसीसी और एमएसवीसी) जो प्रदर्शित करते हैं कि भोलेपन से उत्पन्न त्रुटि संदेश समझ से बाहर हैं। मुझे लगता है कि यह मानना ​​​​एक खिंचाव है कि निहित बाधाओं के लिए त्रुटि संदेश आंतरिक रूप से खराब हैं।

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

मुझे व्यक्तिगत रूप से यह भी नहीं लगता कि स्पष्ट बाधाएं मौजूदा गो दृष्टिकोण के अनुरूप हैं, क्योंकि इंटरफेस स्पष्ट रनटाइम प्रकार की बाधाएं हैं, हालांकि उनके पास सीमित अभिव्यक्ति है।

हमारे पास कुछ उदाहरण हैं (जीसीसी और एमएसवीसी) जो प्रदर्शित करते हैं कि भोलेपन से उत्पन्न त्रुटि संदेश समझ से बाहर हैं। मुझे लगता है कि यह मानना ​​​​एक खिंचाव है कि निहित बाधाओं के लिए त्रुटि संदेश आंतरिक रूप से खराब हैं।

संकलकों की सूची जिस पर गैर-स्थानीय प्रकार का अनुमान - जो आप प्रस्तावित करते हैं - खराब त्रुटि संदेशों में परिणाम उससे काफी लंबा है। इसमें SML, OCaml, और GHC शामिल हैं, जहां पहले से ही उनके त्रुटि संदेशों को सुधारने में बहुत प्रयास किए गए हैं और जहां कम से कम कुछ स्पष्ट मॉड्यूल संरचना मदद कर रही है। आप बेहतर करने में सक्षम हो सकते हैं, और यदि आप अपने द्वारा प्रस्तावित योजना के साथ अच्छे त्रुटि संदेशों के लिए एल्गोरिदम के साथ आते हैं, तो आपके पास एक अच्छा प्रकाशन होगा। उस एल्गोरिथम की ओर एक प्रारंभिक बिंदु के रूप में, आपको त्रुटि स्थानीयकरण पर हमारे POPL 2014 और PLDI 2015 पेपर उपयोगी लग सकते हैं। वे कमोबेश अत्याधुनिक हैं।

क्योंकि सभी वाक्यात्मक बाधाओं को उपयोग से अनुमान लगाया जा सकता है।

क्या यह टाइप-चेक करने योग्य जेनेरिक प्रोग्राम की चौड़ाई को सीमित नहीं करता है? उदाहरण के लिए, ध्यान दें कि टाइप-पैरा प्रस्ताव "इटरेबल" बाधा निर्दिष्ट नहीं करता है। वर्तमान भाषा में, यह या तो एक स्लाइस या चैनल के अनुरूप होगा, लेकिन एक समग्र प्रकार (एक लिंक की गई सूची कहें) उन आवश्यकताओं को पूरा नहीं करेगा। जैसे इंटरफ़ेस को परिभाषित करना

type Iterable[T] interface {
    Next() T
}

लिंक्ड लिस्ट केस में मदद करता है, लेकिन अब इस इंटरफेस को संतुष्ट करने के लिए बिल्टिन स्लाइस और चैनल प्रकारों को बढ़ाया जाना चाहिए।

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

भाषा को उसके उपयोगकर्ताओं के लिए डिज़ाइन किया जाना चाहिए, न कि संकलक-लेखकों के लिए।

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

क्या होगा अगर . के बजाय

type Iterable[T] interface {
    Next() T
}

हमने "इंटरफ़ेस" के विचार को "बाधाओं" से अलग कर दिया। तब हमारे पास हो सकता है

type T generic

type Iterable class {
    Next() T
}

जहां "वर्ग" का अर्थ है हास्केल-शैली टाइपक्लास, जावा-शैली वर्ग नहीं।

"इंटरफ़ेस" से अलग "टाइपक्लास" होने से दो विचारों की कुछ गैर-ऑर्थोगोनैलिटी को साफ़ करने में मदद मिल सकती है। फिर Sortable (सॉर्ट.इंटरफ़ेस को नज़रअंदाज़ करना) कुछ इस तरह दिख सकता है:

type T generic

type Comparable class {
    Less(a, b T) bool
}

type Sortable class {
    Next() Comparable
}

यहाँ @andrewcmyers द्वारा Genus में "टाइप क्लासेस एंड कॉन्सेप्ट्स" सेक्शन और गो के लिए इसकी प्रयोज्यता के बारे में कुछ फीडबैक दिया गया है।

यह खंड बताते हुए प्रकार वर्गों और अवधारणाओं की सीमाओं को संबोधित करता है

सबसे पहले, बाधा संतुष्टि को विशिष्ट रूप से देखा जाना चाहिए

मुझे यकीन नहीं है कि मैं इस सीमा को समझता हूं। पहचानकर्ताओं को अलग करने के लिए बाधा नहीं बांधना इसे किसी दिए गए प्रकार के लिए अद्वितीय होने से रोकता है? यह मुझे लगता है कि जीनस में "कहां" खंड अनिवार्य रूप से किसी दिए गए बाधा से एक प्रकार/बाधा बनाता है, लेकिन यह किसी दिए गए प्रकार से एक चर को तुरंत चालू करने के समान लगता है। इस तरह से एक बाधा एक तरह से मिलती जुलती है।

गो के लिए अनुकूलित बाधा परिभाषाओं का नाटकीय सरलीकरण यहां दिया गया है:

kind Any interface{} // accepts any type that satisfies interface{}.
type T Any // Declare a type of Any kind. Also binds it to an identifier.
kind Eq T == T // accepts any type for which equality is defined.

तो एक नक्शा घोषणा इस प्रकार दिखाई देगी:

type Map[K Eq, V Any] struct {
}

जहां जीनस में, यह ऐसा दिख सकता है:

type Map[K, V] where Eq[K], Any[V] struct {
}

और मौजूदा टाइप-पैरा प्रस्ताव में ऐसा दिखेगा:

type Map[K,V] struct {
}

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

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

यह सीमा गो के लिए कम प्रासंगिक लगती है क्योंकि भाषा में पहले से ही नामित/अनाम प्रकारों और अतिव्यापी इंटरफेस के बीच अच्छे रूपांतरण नियम हैं।

दिए गए उदाहरण मॉडल को एक समाधान के रूप में प्रस्तावित करते हैं, जो कि गो के लिए एक उपयोगी लेकिन आवश्यक विशेषता नहीं है। यदि कोई पुस्तकालय उदाहरण के लिए http.Handler को लागू करने के लिए एक प्रकार की अपेक्षा करता है, और उपयोगकर्ता संदर्भ के आधार पर अलग-अलग व्यवहार चाहता है, तो एडेप्टर लिखना सरल है:

type handleFunc func(http.ResponseWriter, *http.Request)
func (f handlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w,r) }

वास्तव में, मानक पुस्तकालय यही करता है।

@smasher164

सबसे पहले, बाधा संतुष्टि को विशिष्ट रूप से देखा जाना चाहिए
मुझे यकीन नहीं है कि मैं इस सीमा को समझता हूं। पहचानकर्ताओं को अलग करने के लिए एक बाधा नहीं बांधना> इसे किसी दिए गए प्रकार के लिए अद्वितीय होने से रोकता है?

विचार यह है कि जीनस में आप एक ही बाधा को एक ही प्रकार से एक से अधिक तरीकों से संतुष्ट कर सकते हैं, हास्केल के विपरीत। उदाहरण के लिए, यदि आपके पास HashSet[T] है, तो आप सामान्य तरीके से हैश स्ट्रिंग्स में HashSet[String] लिख सकते हैं लेकिन HashSet[String with CaseInsens] को हैश में लिख सकते हैं और स्ट्रिंग्स की तुलना CaseInsens से कर सकते हैं। मॉडल, जो संभावित रूप से केस-असंवेदनशील तरीके से तारों का इलाज करता है। जीनस वास्तव में इन दो प्रकारों को अलग करता है; यह गो के लिए अधिक हो सकता है। भले ही टाइप सिस्टम इसका ट्रैक नहीं रखता है, फिर भी यह महत्वपूर्ण लगता है कि किसी प्रकार द्वारा प्रदान किए गए डिफ़ॉल्ट संचालन को ओवरराइड करने में सक्षम हो।

प्रकार कोई भी इंटरफ़ेस {} // इंटरफ़ेस को संतुष्ट करने वाले किसी भी प्रकार को स्वीकार करता है {}।
टाइप टी कोई भी // किसी भी प्रकार की घोषणा करें। इसे एक पहचानकर्ता से भी बांधता है।
तरह Eq T == T // किसी भी प्रकार को स्वीकार करता है जिसके लिए समानता परिभाषित की गई है।
नक्शा टाइप करें [के ईक, वी कोई भी] संरचना {...
}

जीनस में इसका नैतिक समकक्ष होगा:

constraint Any[T] {}
// Just use Any as if it were a type
constraint Eq[K] {
   boolean equals(K);
}
class Map[K, V] where Eq[K] { ... }

फ़मिलिया में हम केवल लिखेंगे:

interface Eq {
    boolean equals(This);
}
class Map[K where Eq, V] { ... }

संपादित करें: #4146 में वर्णित एक प्रतिबिंबित आधारित समाधान के पक्ष में इसे वापस लेना एक जेनेरिक आधारित समाधान जैसा कि मैंने नीचे वर्णित किया है, रचनाओं की संख्या में रैखिक रूप से बढ़ता है। जबकि एक प्रतिबिंबित आधारित समाधान में हमेशा एक प्रदर्शन बाधा होगी, यह रनटाइम पर खुद को अनुकूलित कर सकता है ताकि रचनाओं की संख्या की परवाह किए बिना बाधा स्थिर रहे।

यह एक प्रस्ताव नहीं है बल्कि एक प्रस्ताव तैयार करते समय विचार करने के लिए एक संभावित उपयोग-मामला है।

आज गो कोड में दो चीजें कॉमन हैं

• अतिरिक्त कार्यक्षमता प्रदान करने के लिए एक इंटरफ़ेस मान लपेटना (एक ढांचे के लिए http.ResponseWriter लपेटना)
• वैकल्पिक तरीके हैं जो कभी-कभी इंटरफ़ेस मानों में होते हैं (जैसे Temporary() bool पर net.Error )

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

type MyError struct {
  error
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.error)
}

यदि आप उस संरचना में कोई त्रुटि लपेटते हैं तो आप मूल त्रुटि पर कोई अतिरिक्त विधि छुपाते हैं।

यदि आप संरचना में त्रुटि को लपेटते नहीं हैं, तो आप अतिरिक्त संदर्भ प्रदान नहीं कर सकते।

मान लीजिए कि स्वीकृत सामान्य प्रस्ताव आपको निम्नलिखित की तरह कुछ परिभाषित करने देता है (मनमाना वाक्यविन्यास जिसे मैंने जानबूझकर बदसूरत बनाने की कोशिश की ताकि कोई भी उस पर ध्यान केंद्रित न करे)

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.E)
}

एम्बेडिंग का लाभ उठाकर हम त्रुटि इंटरफ़ेस को संतुष्ट करने वाले किसी भी ठोस प्रकार को एम्बेड कर सकते हैं और दोनों इसे लपेट सकते हैं और इसके अन्य तरीकों तक पहुंच प्राप्त कर सकते हैं। दुर्भाग्य से यह केवल हमें वहां से अलग कर देता है।

हमें वास्तव में यहां त्रुटि इंटरफ़ेस का एक मनमाना मूल्य लेने और इसके गतिशील प्रकार को एम्बेड करने की आवश्यकता है।

यह तुरंत दो चिंताएं पैदा करता है

• प्रकार को रनटाइम पर बनाना होगा (संभवतः वैसे भी प्रतिबिंबित करने की आवश्यकता है)
• यदि त्रुटि मान शून्य है तो टाइप निर्माण को घबराना होगा

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

इसके बिना आप केवल त्रुटि प्रकार पर MyError को तुरंत चालू कर रहे हैं इंटरफ़ेस का गतिशील प्रकार नहीं।

मान लीजिए कि हमारे पास एक जादुई unbox फ़ंक्शन है जिसे बाहर निकालना है और (किसी तरह) जानकारी को लागू करना है:

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  return MyError{
    E: unbox(err),
    extraContext: ec,
  }
}

अब मान लें कि हमारे पास एक गैर-शून्य त्रुटि है, err , जिसका गतिशील प्रकार *net.DNSError है। फिर यह

wrapped := wrap(getExtraContext(), err)
//wrapped 's dynamic type is a MyStruct embedding E=*net.DNSError
_, ok := wrapped.(net.Error)
fmt.Println(ok)

true प्रिंट करेगा। लेकिन अगर err का डायनामिक प्रकार *os.PathError होता तो यह झूठा प्रिंट होता।

मुझे आशा है कि प्रस्तावित सिमेंटिक प्रदर्शन में इस्तेमाल किए गए मोटे सिंटैक्स को देखते हुए स्पष्ट है।

मुझे यह भी उम्मीद है कि कम तंत्र और समारोह के साथ उस समस्या को हल करने का एक बेहतर तरीका है, लेकिन मुझे लगता है कि उपरोक्त काम कर सकता है।

@jimmyfrasche अगर मैं समझ रहा हूं कि आप क्या चाहते हैं, तो यह एक रैपर मुक्त अनुकूलन तंत्र है। आप मूल को छिपाने वाली किसी अन्य वस्तु में लपेटे बिना किसी प्रकार के ऑफ़र के संचालन के सेट का विस्तार करने में सक्षम होना चाहते हैं। यह एक कार्यक्षमता है जो Genus प्रदान करता है।

@andrewcmyers नं।

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

type S struct {
  T
}

तथा

type S struct {
  T T
}
func (s S) Foo() {
  s.T.Foo()
}

(जब फू को इसका "यह" हमेशा टाइप टी कहा जाता है)।

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

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

func isTemp(err error) bool {
  if t, ok := err.(interface{ Temporary() bool}); ok {
    return t.Temporary()
  }
  return false
}

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

type A struct {}
func (A) Foo()
func (A) Bar()

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

आप Bar को i $ पर कॉल नहीं कर सकते हैं या यह भी नहीं जानते कि यह तब तक मौजूद है जब तक आप नहीं जानते कि मैं गतिशील प्रकार एक बी है, इसलिए आप इसे खोल सकते हैं और I फ़ील्ड पर उस पर जोर देने के लिए प्राप्त कर सकते हैं .

यह वास्तविक समस्याओं का कारण बनता है, विशेष रूप से त्रुटि, या रीडर जैसे सामान्य इंटरफेस से निपटना।

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

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

@jimmyfrasche @andrewcmyers उस उपयोग के मामले के लिए, https://github.com/golang/go/issues/4146#issuecomment -318200547 भी देखें।

@jimmyfrasche मेरे लिए, ऐसा लगता है कि यहां महत्वपूर्ण समस्या एक चर के गतिशील प्रकार/मान प्राप्त कर रही है। एम्बेडिंग को अलग रखते हुए, एक सरल उदाहरण होगा

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  e E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.e)
}

e को असाइन किया गया मान $#$2 *net.DNSError #$ जैसे गतिशील (या ठोस) प्रकार का होना चाहिए, जो error लागू करता है। यहां कुछ संभावित तरीके दिए गए हैं जिनसे भविष्य में भाषा परिवर्तन इस समस्या से निपट सकता है:

1. एक जादुई unbox जैसा फ़ंक्शन है जो एक चर के गतिशील मान को उजागर करता है। यह किसी भी प्रकार पर लागू होता है जो ठोस नहीं है, उदाहरण के लिए संघ।
2. यदि भाषा परिवर्तन प्रकार चर का समर्थन करता है, तो गतिशील प्रकार के चर प्राप्त करने के लिए एक साधन प्रदान करें। प्रकार की जानकारी के साथ, हम स्वयं unbox फ़ंक्शन लिख सकते हैं। उदाहरण के लिए,

func unbox(v T1) T2 {
    t := dynTypeOf(v)
    return v.(t)
}

wrap को पहले की तरह ही लिखा जा सकता है, या

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  t := dynTypeOf(err)
  return MyError{
    e: v.(t),
    extraContext: ec,
  }
}

1. यदि भाषा परिवर्तन प्रकार की बाधाओं का समर्थन करता है, तो यहां एक वैकल्पिक विचार दिया गया है:

type E1 which_is_a_type_satisfying error
type E2 which_is_a_type_satisfying error

func wrap(ec extraContext, err E1) E2 {
  if err == nil {
    return nil
  }
  return MyError{
    e: err,
    extraContext: ec,
  }
}

इस उदाहरण में, हम त्रुटि को लागू करने वाले किसी भी प्रकार के मान को स्वीकार करते हैं। wrap error की अपेक्षा करता है, उसे एक प्राप्त होगा। हालाँकि, e के अंदर MyError का प्रकार वही है जो err में पारित किया गया है, जो एक इंटरफ़ेस प्रकार तक सीमित नहीं है। अगर कोई 2 जैसा व्यवहार चाहता है,

var iface error = ...
wrap(getExtraContext(), unbox(iface))

चूंकि किसी और ने ऐसा नहीं किया है, इसलिए मैं जेनेरिक के लिए बहुत स्पष्ट "अनुभव रिपोर्ट" को इंगित करना चाहता हूं जिसे https://blog.golang.org/toward-go2 द्वारा बुलाया गया है।

पहला अंतर्निहित map प्रकार है:

m := make(map[string]string)

अगला अंतर्निहित chan प्रकार है:

c := make(chan bool)

अंत में, मानक पुस्तकालय interface{} विकल्पों से भरा हुआ है जहां जेनेरिक अधिक सुरक्षित रूप से काम करेंगे:

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#Pool)
• आगामी sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

कुछ और भी हो सकते हैं जो मुझे याद आ रहे हैं। मुद्दा यह है कि उपरोक्त में से प्रत्येक वह जगह है जहां मैं जेनरिक के उपयोगी होने की अपेक्षा करता हूं।

(नोट: मैं यहां sort.Sort शामिल नहीं कर रहा हूं क्योंकि यह एक उत्कृष्ट उदाहरण है कि जेनरिक के बजाय इंटरफेस का उपयोग कैसे किया जा सकता है।)

http://www.yinwang.org/blog-cn/2014/04/18/golang
मुझे लगता है कि सामान्य महत्वपूर्ण है। अन्यथा, समान प्रकारों को संभाल नहीं सकता है। कभी-कभी इंटरफ़ेस समस्या का समाधान नहीं कर सकता है।

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

@bxqgit कृपया इसे सिविल रखें। किसी का अपमान करने की जरूरत नहीं है।

भविष्य क्या लाएगा, हम देखेंगे, लेकिन मुझे पता है कि मेरे समय के 98% के लिए मुझे जेनरिक की आवश्यकता नहीं है, जब भी मुझे उनकी आवश्यकता होती है, काश मैं उनका उपयोग कर पाता। उनका उपयोग कैसे किया जाता है बनाम उनका गलत तरीके से उपयोग कैसे किया जाता है यह एक अलग चर्चा है। उपयोगकर्ताओं को शिक्षित करना प्रक्रिया का हिस्सा होना चाहिए।

@bxqgit
ऐसी स्थितियां हैं जिनमें जेनरिक की आवश्यकता होती है, जैसे सामान्य डेटा संरचनाएं (पेड़, ढेर, कतार, ...) या सामान्य कार्य (मानचित्र, फ़िल्टर, कम करें, ...) ये स्थितियां कोड लेखक और कोड रीडर दोनों के लिए एक बड़ी जटिलता जोड़ती हैं और इसका रन-टाइम पर कोड दक्षता पर भी बुरा प्रभाव पड़ता है, इसलिए इंटरफेस का उपयोग करने और जटिल लिखने के लिए प्रतिबिंबित करने की कोशिश करने से भाषा जेनेरिक में जोड़ने के लिए यह अधिक तर्कसंगत होना चाहिए और अक्षम कोड।

@bxqgit जेनरिक जोड़ना जरूरी नहीं कि भाषा में जटिलता जोड़ता है, इसे सरल सिंटैक्स के साथ भी हासिल किया जा सकता है। जेनरिक के साथ, आप एक चर संकलन समय प्रकार की बाधा जोड़ रहे हैं जो डेटा संरचनाओं के साथ बहुत उपयोगी है, जैसा कि @riwogo ने कहा।

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

इसके अलावा, याद रखें, पीछे जाने वाले लोग, जिसे आप "सीएस सिद्धांत और गणित" कहते हैं, का उपयोग करके भाषा विकसित करते हैं, और वे लोग भी हैं जो "इसे पूरा कर रहे हैं"।

इसके अलावा, याद रखें, पीछे जाने वाले लोग, जिसे आप "सीएस सिद्धांत और गणित" कहते हैं, का उपयोग करके भाषा विकसित करते हैं, और वे लोग भी हैं जो "इसे पूरा कर रहे हैं"।

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

टेम्प्लेट जटिल है लेकिन जेनरिक सरल है

सॉर्ट पैकेज में SortInts, SortFloats, SortStrings के कार्यों को देखें। या सर्चइंट्स, सर्चफ्लोट्स, सर्चस्ट्रिंग्स। या पैकेज io/ioutil में byName की लेन, कम और स्वैप विधियाँ। शुद्ध बॉयलरप्लेट नकल।

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

मेरा वोट सामान्यीकृत एप्लिकेशन जेनरिक के लिए नहीं है, हाँ append और copy जैसे अधिक अंतर्निहित सामान्य कार्यों के लिए जो कई आधार प्रकारों पर काम करते हैं। शायद sort और search संग्रह प्रकारों के लिए जोड़ा जा सकता है?

मेरे अनुप्रयोगों के लिए एकमात्र प्रकार गायब है एक अनियंत्रित सेट (https://github.com/golang/go/issues/7088), मैं इसे एक अंतर्निर्मित प्रकार के रूप में चाहता हूं ताकि इसे सामान्य टाइपिंग जैसे slice मिल जाए map । काम को कंपाइलर में डालें (प्रत्येक आधार प्रकार के लिए बेंचमार्किंग और struct प्रकारों का एक चयनित सेट और फिर सर्वश्रेष्ठ प्रदर्शन के लिए ट्यूनिंग) और एप्लिकेशन कोड से अतिरिक्त एनोटेशन रखें।

कृपया $#$ sync.Map के बजाय smap बिल्ट-इन भी करें। मेरे अनुभव से रनटाइम प्रकार की सुरक्षा के लिए interface{} का उपयोग करना एक डिज़ाइन दोष है। गो का उपयोग करने के लिए कंपाइल-टाइम टाइप चेकिंग एक प्रमुख कारण है।

@pciet

रनटाइम प्रकार की सुरक्षा के लिए इंटरफ़ेस {} का उपयोग करने के मेरे अनुभव से एक डिज़ाइन दोष है।

क्या आप बस एक छोटा (टाइप सेफ) रैपर लिख सकते हैं?
https://play.golang.org/p/tG6hd-j5yx

@pierrre वह रैपर reflect.TypeOf(item).AssignableTo(type) चेक से बेहतर है। लेकिन map + sync.Mutex या sync.RWMutex के साथ अपना खुद का प्रकार लिखना उसी प्रकार की जटिलता है जो sync.Map के लिए आवश्यक है।

मेरे सिंक्रनाइज़ किए गए मानचित्र का उपयोग म्यूटेक्स के वैश्विक मानचित्रों के लिए एक प्रकार बनाने के बजाय इसके आगे var myMapLock = sync.RWMutex{} के साथ किया गया है। यह क्लीनर हो सकता है। एक सामान्य अंतर्निर्मित प्रकार मुझे सही लगता है लेकिन वह काम करता है जो मैं नहीं कर सकता, और मैं जोर देने के बजाय अपना दृष्टिकोण पसंद करता हूं।

मुझे संदेह है कि जेनेरिकों के लिए नकारात्मक आंत प्रतिक्रिया उत्पन्न होती है जो कई गो प्रोग्रामर उत्पन्न होती है क्योंकि जेनरिक के लिए उनका मुख्य जोखिम सी ++ टेम्पलेट्स के माध्यम से था। यह दुर्भाग्यपूर्ण है क्योंकि C++ को पहले दिन से ही जेनरिक ट्रैजिक रूप से गलत हो गया था और तब से वह गलती को बढ़ा रहा है। गो के लिए जेनरिक बहुत सरल और कम त्रुटि-प्रवण हो सकता है।

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

@andrewcmyers "जेनेरिक फॉर गो बहुत सरल और कम त्रुटि-प्रवण हो सकता है।" --- सी # में जेनरिक की तरह।

बिल्ट-इन पैरामीटरयुक्त प्रकारों को जोड़कर गो को अधिक से अधिक जटिल होते हुए देखना निराशाजनक है।

इस मुद्दे में अटकलों के बावजूद, मुझे लगता है कि ऐसा होने की संभावना बहुत कम है।

पैरामीटरयुक्त प्रकारों की जटिलता माप पर घातांक विचरण है।
गो के प्रकार (इंटरफ़ेस को छोड़कर) अपरिवर्तनीय हैं और यह हो सकता है और होना चाहिए
नियम रखा।

एक यांत्रिक, संकलक-सहायता प्राप्त "टाइप कॉपी-पास्टर" जेनरिक कार्यान्वयन
गो के अंतर्निहित के लिए सही फैशन में 99% समस्या का समाधान करेगा
उथलेपन और गैर-आश्चर्य के सिद्धांत।

वैसे, इस और दर्जनों अन्य व्यवहार्य विचारों पर चर्चा की गई है
पहले और कुछ की परिणति अच्छे, व्यावहारिक दृष्टिकोणों में भी हुई। इस पर
बिंदु, मैं सीमा रेखा टिनफ़ोइल-नफरत कर रहा हूं कि वे सभी कैसे गायब हो गए
चुपचाप शून्य में।

28 नवंबर, 2017 23:54 को, "एंड्रयू मायर्स" नोटिफिकेशन @github.com ने लिखा:

मुझे संदेह है कि जेनेरिक के लिए नकारात्मक आंत की प्रतिक्रिया है कि कई गो
ऐसा लगता है कि प्रोग्रामर उत्पन्न हुए हैं क्योंकि जेनरिक के लिए उनका मुख्य प्रदर्शन था
सी ++ टेम्पलेट्स के माध्यम से। यह दुर्भाग्यपूर्ण है क्योंकि सी ++ को जेनरिक दुखद रूप से मिला है
1 दिन से गलत है और तब से गलती को बढ़ा रहा है। के लिए जेनरिक
गो बहुत सरल और कम त्रुटि-प्रवण हो सकता है।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-347691444 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AJZ_jPsQd2qBbn9NI1wZeT-O2JpyraTMks5s7I81gaJpZM4IG-xv
.

हां, आपके पास बिना टेम्प्लेट के जेनरिक हो सकते हैं। टेम्प्लेट उन्नत पैरामीट्रिक बहुरूपता का एक रूप है जो ज्यादातर मेटाप्रोग्रामिंग सुविधाओं के लिए होता है।

@ianlancetaylor Rust एक प्रोग्राम को मौजूदा प्रकार Q T को लागू करने की अनुमति देता है, बशर्ते कि उनका टोकरा T या Q को परिभाषित करे।

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

फिलिप वाडलर भी हैं, जिन्होंने जेनेरिक जावा पर काम किया, जो अंततः जावा के जेनेरिक कार्यान्वयन की ओर ले जाता है।

@tarcieri मुझे नहीं लगता कि जावा के जेनरिक बहुत अच्छे हैं, लेकिन वे युद्ध-परीक्षण हैं।

@DemiMarie हमने सौभाग्य से एंड्रयू मायर्स को यहां पिच किया है।

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

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

वास्तव में, जब मैं यहां हूं, कुछ समय पहले मैंने कुछ समय के लिए इंटरफेस के साथ सामान्य प्रोग्रामिंग के बारे में सोचा, और तीन कारणों के साथ आया कि यह संतोषजनक क्यों नहीं है।

1. इंटरफेस को सभी कार्यों को विधियों के रूप में व्यक्त करने की आवश्यकता होती है। इससे चैनल प्रकारों जैसे बिल्टिन प्रकारों के लिए इंटरफ़ेस लिखना दर्दनाक हो जाता है। सभी प्रकार के चैनल भेजने और प्राप्त करने के संचालन के लिए <- ऑपरेटर का समर्थन करते हैं, और Send और Receive विधियों के साथ एक इंटरफ़ेस लिखना काफी आसान है, लेकिन चैनल मान निर्दिष्ट करने के लिए उस इंटरफ़ेस प्रकार के लिए आपको बॉयलरप्लेट प्लेट Send और Receive विधियों को लिखना होगा। वे बॉयलरप्लेट विधियाँ प्रत्येक भिन्न चैनल प्रकार के लिए ठीक वैसी ही दिखाई देंगी, जो थकाऊ है।

2. इंटरफेस गतिशील रूप से टाइप किए जाते हैं, और इसलिए विभिन्न सांख्यिकीय रूप से टाइप किए गए मानों को संयोजित करने वाली त्रुटियां केवल रन टाइम पर पकड़ी जाती हैं, संकलन समय पर नहीं। उदाहरण के लिए, एक Merge फ़ंक्शन जो दो चैनलों को उनके Send और Receive विधियों का उपयोग करके एक चैनल में मर्ज करता है, के लिए दोनों चैनलों में एक ही प्रकार के तत्व होने की आवश्यकता होगी, लेकिन वह चेक केवल रन टाइम पर ही किया जा सकता है।

3. इंटरफेस हमेशा बॉक्सिंग होते हैं। उदाहरण के लिए, उन अन्य प्रकारों को इंटरफ़ेस मानों में डाले बिना अन्य प्रकारों की एक जोड़ी को एकत्रित करने के लिए इंटरफेस का उपयोग करने का कोई तरीका नहीं है, अतिरिक्त मेमोरी आवंटन और पॉइंटर पीछा करने की आवश्यकता होती है।

मुझे गो के लिए जेनरिक प्रस्तावों पर किबिट्ज़ से प्रसन्नता हो रही है। हाल ही में कॉर्नेल में जेनरिक पर शोध की बढ़ती मात्रा में रुचि भी हो सकती है, जो गो के साथ किया जा सकता है के लिए प्रासंगिक प्रतीत होता है:

http://www.cs.cornell.edu/andru/papers/familia/ (झांग एंड मायर्स, OOPSLA'17)
http://io.livecode.ch/learn/namin/unsound (अमीन एंड टेट, OOPSLA'16)
http://www.cs.cornell.edu/projects/genus/ (झांग एट अल।, पीएलडीआई '15)
https://www.cs.cornell.edu/~ross/publications/shapes/shapes-pldi14.pdf (ग्रीनमैन, मुएहलबोएक एंड टेट, पीएलडीआई '14)

एक अनियंत्रित सेट प्रकार के लिए बेंचमार्किंग मानचित्र बनाम स्लाइस में मैंने प्रत्येक के लिए अलग-अलग यूनिट परीक्षण लिखे, लेकिन इंटरफ़ेस प्रकारों के साथ मैं उन दो परीक्षण सूचियों को एक में जोड़ सकता हूं:

type Item interface {
    Equal(Item) bool
}

type Set interface {
    Add(Item) Set
    Remove(Item) Set
    Combine(...Set) Set
    Reduce() Set
    Has(Item) bool
    Equal(Set) bool
    Diff(Set) Set
}

किसी आइटम को निकालने का परीक्षण:

type RemoveCase struct {
    Set
    Item
    Out Set
}

func TestRemove(t *testing.T) {
    for i, c := range RemoveCases {
        if c.Out.Equal(c.Set.Remove(c.Item)) == false {
            t.Fatalf("%v failed", i)
        }
    }
}

इस तरह मैं अपने पहले के अलग-अलग मामलों को बिना किसी परेशानी के मामलों के एक टुकड़े में डाल सकता हूं:

var RemoveCases = []RemoveCase{
    {
        Set: MapPathSet{
            &Path{{0, 0}}:         {},
            &Path{{0, 1}, {1, 1}}: {},
        },
        Item: Path{{0, 0}},
        Out: MapPathSet{
            &Path{{0, 1}, {1, 1}}: {},
        },
    },
    {
        Set: SlicePathSet{
            {{0, 0}},
            {{0, 1}, {1, 1}},
        },
        Item: Path{{0, 0}},
        Out: SlicePathSet{
            {{0, 1}, {1, 1}},
        },
    },
}

प्रत्येक ठोस प्रकार के लिए मुझे इंटरफ़ेस विधियों को परिभाषित करना था। उदाहरण के लिए:

func (the MapPathSet) Remove(an Item) Set {
    return MapDelete(the, an.(Path))
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an.(Path))
}

ये सामान्य परीक्षण प्रस्तावित संकलन-समय प्रकार की जांच का उपयोग कर सकते हैं:

type Item generic {
    Equal(Item) bool
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an)
}

स्रोत: https://github.com/pciet/pathsetbenchmark

इसके बारे में और सोचकर, ऐसा प्रतीत नहीं होता है कि इस तरह के परीक्षण के लिए संकलन-समय प्रकार की जांच संभव होगी क्योंकि आपको यह जानने के लिए प्रोग्राम चलाना होगा कि कोई प्रकार संबंधित इंटरफ़ेस विधि को पास किया गया है या नहीं।

तो एक "जेनेरिक" प्रकार के बारे में क्या है जो एक इंटरफ़ेस है और इसमें एक अदृश्य प्रकार का दावा है जब संकलक द्वारा समेकित रूप से उपयोग किया जाता है?

@andrewcmyers "फ़मिलिया" पेपर दिलचस्प था (और मेरे सिर पर रास्ता)। एक प्रमुख धारणा विरासत थी। गो जैसी भाषा के लिए अवधारणा कैसे बदलेगी जो विरासत के बजाय संरचना पर निर्भर करती है?

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

@andrewcmyers क्या आप इसका उदाहरण दे सकते हैं कि यह गो में कैसा दिखेगा?

गो के लिए प्रासंगिक उस पेपर के बारे में मुख्य बात यह है कि यह दिखाता है कि इंटरफेस का उपयोग कैसे किया जाता है, जिस तरह से वे गो के लिए उपयोग किए जाते हैं और जेनेरिक एब्स्ट्रैक्शन के प्रकारों पर बाधाओं के रूप में।

मेरी समझ यह है कि गो इंटरफ़ेस एक प्रकार पर एक बाधा को परिभाषित करता है (उदाहरण के लिए "इस प्रकार की तुलना 'प्रकार तुलनात्मक इंटरफ़ेस' का उपयोग करके समानता के लिए की जा सकती है क्योंकि यह एक ईक विधि को संतुष्ट करता है")। मुझे यकीन नहीं है कि मैं समझता हूं कि एक प्रकार की बाधा से आपका क्या मतलब है।

मैं हास्केल से परिचित नहीं हूं लेकिन एक त्वरित अवलोकन पढ़ने से मुझे लगता है कि गो इंटरफ़ेस फिट करने वाले प्रकार उस प्रकार के वर्ग में फिट होंगे। क्या आप बता सकते हैं कि हास्केल प्रकार की कक्षाओं के बारे में क्या अलग है?

फ़मिलिया और गो के बीच एक ठोस तुलना दिलचस्प होगी। अपना पेपर साझा करने के लिए धन्यवाद।

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

गो में अधिक सामान्य प्रोग्रामिंग सुविधाओं के लिए प्रेरणा पर कुछ विचार:

तो मेरी सामान्य परीक्षण सूची है जिसे वास्तव में भाषा में कुछ भी जोड़ने की आवश्यकता नहीं है। मेरी राय में कि मेरे द्वारा प्रस्तावित सामान्य प्रकार सीधी समझ के गो लक्ष्य को संतुष्ट नहीं करता है, इसका आम तौर पर स्वीकृत प्रोग्रामिंग शब्द से कोई लेना-देना नहीं है, और प्रकार का दावा करना बदसूरत नहीं था क्योंकि विफलता पर घबराहट है बढ़िया। मैं अपनी जरूरत के लिए पहले से ही गो की सामान्य प्रोग्रामिंग सुविधाओं से संतुष्ट हूं।

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

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

नियमित मानचित्र में केवल एक संकलन-समय प्रकार की जाँच होती है और इसके लिए इस मचान की आवश्यकता नहीं होती है। मेरा तर्क है कि सिंक। मैप समान होना चाहिए या गो 2 के लिए मानक पुस्तकालय में नहीं होना चाहिए।

मैंने बिल्ट-इन प्रकारों की सूची में सिंक.मैप जोड़ने का प्रस्ताव रखा और भविष्य में इसी तरह की जरूरतों के लिए ऐसा करने के लिए। लेकिन मेरी समझ गो प्रोग्रामर को कंपाइलर पर काम किए बिना ऐसा करने का एक तरीका दे रही है और इस चर्चा के पीछे ओपन सोर्स स्वीकृति गौंटलेट का विचार है। मेरे विचार में सिंक को ठीक करना। मैप एक वास्तविक मामला है जो आंशिक रूप से परिभाषित करता है कि यह जेनेरिक प्रस्ताव क्या होना चाहिए।

यदि आप सिंक जोड़ते हैं। एक अंतर्निहित के रूप में मानचित्र करें, तो आप कितनी दूर जाते हैं? क्या आप हर कंटेनर में विशेष मामला रखते हैं?
sync.Map एकमात्र कंटेनर नहीं है और कुछ अन्य की तुलना में कुछ मामलों के लिए बेहतर हैं।

@Azareal : @chowey ने इन्हें अगस्त में सूचीबद्ध किया था:

अंत में, मानक पुस्तकालय इंटरफ़ेस {} विकल्पों से भरा हुआ है जहां जेनरिक अधिक सुरक्षित रूप से काम करेगा:

• ढेर.इंटरफेस (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• रिंग.रिंग (https://golang.org/pkg/container/ring/#Ring)
• सिंक.पूल (https://golang.org/pkg/sync/#Pool)
• आगामी सिंक.मैप (https://tip.golang.org/pkg/sync/#Map)
• परमाणु मूल्य (https://golang.org/pkg/sync/atomic/#Value)

कुछ और भी हो सकते हैं जो मुझे याद आ रहे हैं। मुद्दा यह है कि उपरोक्त में से प्रत्येक वह जगह है जहां मैं जेनरिक के उपयोगी होने की अपेक्षा करता हूं।

और मुझे उन प्रकारों के लिए अनियंत्रित सेट चाहिए जिनकी तुलना समानता के लिए की जा सकती है।

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

मैं सोच रहा हूं कि क्या गो 1 के साथ उचित वैकल्पिक कार्यान्वयन हैं जो इन मानक पुस्तकालय प्रकारों के लिए इंटरफ़ेस {} और बिना जेनरिक के समान लक्ष्य प्राप्त करते हैं।

गोलांग इंटरफेस और हैकेल प्रकार की कक्षाएं दो चीजों पर काबू पाती हैं (जो बहुत बढ़िया हैं!):

1.) (प्रकार की कमी) वे एक टैग के साथ विभिन्न प्रकारों को समूहित करते हैं, इंटरफ़ेस नाम
2.) (डिस्पैच) वे इंटरफ़ेस कार्यान्वयन के माध्यम से कार्यों के दिए गए सेट के लिए प्रत्येक प्रकार पर अलग-अलग प्रेषण करने की पेशकश करते हैं

लेकिन,

1.) कभी-कभी आप केवल अज्ञात समूह चाहते हैं जैसे int, float64 और string का समूह। आपको ऐसे इंटरफ़ेस का नाम कैसे देना चाहिए, न्यूमेरिकैंडस्ट्रिंग?

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

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

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

वैसे।
मैं उन लोगों को स्वीकार करता हूं जो कहते हैं कि गो में पहले से ही बहुरूपता है और इसलिए गो अब सी जैसी सरल भाषा नहीं है। यह एक उच्च स्तरीय सिस्टम प्रोग्रामिंग भाषा है। तो क्यों न बहुरूपता गो ऑफर का विस्तार किया जाए।

यहाँ एक पुस्तकालय है जिसे मैंने आज सामान्य अनियंत्रित सेट प्रकारों के लिए शुरू किया है: https://github.com/pciet/unordered

यह प्रलेखन और परीक्षण उदाहरणों में देता है जो संकलन-समय प्रकार की सुरक्षा के लिए रैपर पैटर्न (धन्यवाद @pierrre) टाइप करते हैं और रन-टाइम प्रकार की सुरक्षा के लिए प्रतिबिंबित जांच भी करते हैं।

जेनरिक के लिए क्या जरूरतें हैं? मानक पुस्तकालय सामान्य प्रकारों के प्रति मेरा नकारात्मक रवैया पहले इंटरफेस के उपयोग के आसपास केंद्रित था {}; मेरी शिकायत को इंटरफ़ेस के लिए एक पैकेज-विशिष्ट प्रकार के साथ हल किया जा सकता है {} (जैसे type Item interface{} pciet/unordered में) जो इच्छित गैर-व्यक्त बाधाओं को दस्तावेज करता है।

मुझे एक अतिरिक्त भाषा सुविधा की आवश्यकता नहीं दिख रही है, जब सिर्फ दस्तावेज़ीकरण हमें वहां पहुंचा सकता है। मानक पुस्तकालय में पहले से ही बड़ी मात्रा में युद्ध-परीक्षण कोड है जो सामान्य सुविधाएं प्रदान करता है (देखें https://github.com/golang/go/issues/23077)।

रनटाइम में आपका कोड टाइप-चेक (और उस परिप्रेक्ष्य से यह किसी भी तरह से interface{} से बेहतर नहीं है यदि बदतर नहीं है)। जेनरिक के साथ आप संकलन-समय प्रकार की जांच के साथ संग्रह प्रकार प्राप्त कर सकते थे।

@zerkms रन-टाइम चेक को मुखर = गलत (यह मानक पुस्तकालय में नहीं जाएगा) सेट करके बंद किया जा सकता है, संकलन-समय की जांच के लिए एक उपयोग पैटर्न है, और वैसे भी एक प्रकार की जांच सिर्फ इंटरफ़ेस संरचना को देखती है (उपयोग करके) इंटरफ़ेस टाइप चेक से अधिक खर्च जोड़ता है)। यदि इंटरफ़ेस प्रदर्शन नहीं कर रहा है तो आपको अपना खुद का प्रकार लिखना होगा।

आप कह रहे हैं कि अधिकतम-प्रदर्शन सामान्य कोड एक महत्वपूर्ण आवश्यकता है। यह मेरे उपयोग के मामलों के लिए नहीं है, लेकिन हो सकता है कि मानक पुस्तकालय तेज हो जाए, और शायद दूसरों को ऐसी चीज की आवश्यकता हो।

रन-टाइम चेक को असेटिंग = असत्य . सेट करके बंद किया जा सकता है

तो कुछ भी शुद्धता की गारंटी नहीं देता

आप कह रहे हैं कि अधिकतम-प्रदर्शन सामान्य कोड एक महत्वपूर्ण आवश्यकता है।

मैंने वैसा नहीं कहा। टाइप सेफ्टी बहुत बड़ी बात होगी। आपका समाधान अभी भी interface{} -संक्रमित है।

लेकिन शायद मानक पुस्तकालय तेज हो सकता है, और शायद दूसरों को ऐसी चीज की जरूरत है।

हो सकता है, अगर कोर देव टीम मुझे मांग पर और जल्दी से जो कुछ भी चाहिए उसे लागू करने में प्रसन्नता हो।

@pciet

मुझे एक अतिरिक्त भाषा सुविधा की आवश्यकता नहीं दिख रही है, जब सिर्फ दस्तावेज़ीकरण हमें वहां पहुंचा सकता है।

आप यह कहते हैं, फिर भी आपको स्लाइस और मेक फ़ंक्शन के रूप में सामान्य भाषा सुविधाओं का उपयोग करने में कोई समस्या नहीं है।

मुझे एक अतिरिक्त भाषा सुविधा की आवश्यकता नहीं दिख रही है, जब सिर्फ दस्तावेज़ीकरण हमें वहां पहुंचा सकता है।

फिर स्थिर रूप से टाइप की गई भाषा का उपयोग करने से क्यों परेशान हैं? आप पाइथन जैसी गतिशील रूप से टाइप की गई भाषा का उपयोग कर सकते हैं और यह सुनिश्चित करने के लिए दस्तावेज़ीकरण पर भरोसा कर सकते हैं कि आपके एपीआई को सही डेटा प्रकार भेजे गए हैं।

मुझे लगता है कि गो के फायदों में से एक भविष्य की बग को रोकने के लिए संकलक द्वारा कुछ बाधाओं को लागू करने की सुविधा है। भविष्य में कुछ और बग को रोकने के लिए कुछ अन्य बाधाओं को लागू करने के लिए उन सुविधाओं को (जेनेरिक समर्थन के साथ) बढ़ाया जा सकता है।

आप यह कहते हैं, फिर भी आपको स्लाइस और मेक फ़ंक्शन के रूप में सामान्य भाषा सुविधाओं का उपयोग करने में कोई समस्या नहीं है।

मैं कह रहा हूं कि मौजूदा सुविधाएं हमें एक अच्छे संतुलित बिंदु पर ले जाती हैं जिसमें सामान्य प्रोग्रामिंग समाधान होते हैं और गो 1 प्रकार प्रणाली से बदलने के लिए मजबूत वास्तविक कारण होने चाहिए। यह नहीं कि परिवर्तन से भाषा कैसे सुधरेगी, लेकिन लोगों को अब किन समस्याओं का सामना करना पड़ रहा है, जैसे कि fmt और डेटाबेस मानक लाइब्रेरी पैकेज में इंटरफ़ेस {} के लिए बहुत सारे रन-टाइम टाइप स्विचिंग को बनाए रखना, जिसे ठीक किया जाएगा।

फिर स्थिर रूप से टाइप की गई भाषा का उपयोग करने से क्यों परेशान हैं? आप पाइथन जैसी गतिशील रूप से टाइप की गई भाषा का उपयोग कर सकते हैं और यह सुनिश्चित करने के लिए दस्तावेज़ीकरण पर भरोसा कर सकते हैं कि आपके एपीआई को सही डेटा प्रकार भेजे गए हैं।

मैंने स्टैटिकली टाइप की गई भाषाओं और संगठनों के बजाय पायथन में सिस्टम लिखने के सुझाव सुने हैं।

अधिकांश गो प्रोग्रामर मानक पुस्तकालय उपयोग प्रकारों का उपयोग करते हैं जिन्हें बिना दस्तावेज़ीकरण या कार्यान्वयन को देखे बिना पूरी तरह से वर्णित नहीं किया जा सकता है। पैरामीट्रिक उप-प्रकार वाले प्रकार या लागू बाधाओं वाले सामान्य प्रकार केवल इन मामलों के सबसेट को प्रोग्रामेटिक रूप से ठीक करते हैं और मानक पुस्तकालय में पहले से ही किए गए बहुत सारे काम उत्पन्न करेंगे।

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

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

यदि गो इंटरफेस कार्यान्वयनकर्ता के प्रकार को पकड़ सकता है, तो जेनरिक का एक रूप हो सकता है जो वर्तमान गो सिंटैक्स के साथ पूरी तरह से संगत है - जेनरिक ( प्रदर्शन ) का एकल पैरामीटर रूप।

@ dc0d जेनेरिक कंटेनर प्रकारों के लिए मेरा मानना ​​​​है कि सुविधा एक रैपर प्रकार की आवश्यकता के बिना संकलन-समय प्रकार की जाँच जोड़ती है: https://gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pciet आप सही कह रहे हैं। दिए गए कोड में, नंबर 4, नमूना बताता है कि स्लाइस और चैनल (और सरणियों) के लिए प्रकार कैप्चर किया गया है। लेकिन नक्शे के लिए नहीं, क्योंकि केवल एक और केवल एक प्रकार का पैरामीटर है: कार्यान्वयनकर्ता। और चूंकि मानचित्र को दो प्रकार के पैरामीटर की आवश्यकता होती है, इसलिए रैपर इंटरफेस की आवश्यकता होती है।

बीटीडब्ल्यू मुझे विचार की एक पंक्ति के रूप में उस कोड के प्रदर्शन उद्देश्य पर जोर देना है। मैं कोई भाषा डिजाइनर नहीं हूं। यह गो में जेनरिक के कार्यान्वयन के बारे में सोचने का एक काल्पनिक तरीका है:

• वर्तमान गो के साथ संगत
• सरल (एकल सामान्य प्रकार पैरामीटर, जो _feels_ जैसे _this_ अन्य OO में, वर्तमान कार्यान्वयनकर्ता के संदर्भ में)

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

@adg ने लिखा:

इस मुद्दे के साथ @ianlancetaylor का एक सामान्य जेनेरिक प्रस्ताव है जिसमें गो के लिए सामान्य प्रोग्रामिंग तंत्र के चार विशिष्ट त्रुटिपूर्ण प्रस्ताव शामिल हैं।

Afaics, लिंक किया गया अंश इस प्रकार है, वर्तमान इंटरफेस के साथ सामान्यता की कमी के मामले को बताने में विफल रहता है, _ "ऐसा कोई तरीका लिखने का कोई तरीका नहीं है जो किसी भी T के लिए कॉलर द्वारा आपूर्ति किए गए प्रकार T के लिए एक इंटरफ़ेस लेता है, और का मान देता है एक ही प्रकार टी। ”_।

ऐसी विधि के साथ इंटरफ़ेस लिखने का कोई तरीका नहीं है जो किसी भी टी के लिए टाइप टी का तर्क लेता है, और उसी प्रकार का मान देता है।

तो कॉल साइट प्रकार पर कोड और कैसे जांच सकता है कि परिणाम मूल्य के रूप में इसका एक प्रकार टी है? उदाहरण के लिए, उक्त इंटरफ़ेस में टाइप T के निर्माण के लिए फ़ैक्टरी विधि हो सकती है। यही कारण है कि हमें टाइप T पर इंटरफ़ेस को पैरामीट्रिज़ करने की आवश्यकता है।

इंटरफेस केवल प्रकार नहीं हैं; वे भी मूल्य हैं। इंटरफ़ेस मानों का उपयोग किए बिना इंटरफ़ेस प्रकारों का उपयोग करने का कोई तरीका नहीं है, और इंटरफ़ेस मान हमेशा कुशल नहीं होते हैं।

सहमत हैं कि चूंकि इंटरफेस को वर्तमान में टाइप टी पर स्पष्ट रूप से पैरामीट्रिज नहीं किया जा सकता है, इसलिए टाइप टी प्रोग्रामर के लिए सुलभ नहीं है।

तो यह टाइपक्लास बाउंड्स फंक्शन डेफिनिशन साइट पर टाइप टी इनपुट के रूप में लेते हैं और where या requires क्लॉज होते हैं जो टाइप टी के लिए आवश्यक इंटरफेस बताते हैं। कई परिस्थितियों में इन इंटरफ़ेस शब्दकोशों को संकलन-समय पर स्वचालित रूप से मोनोमोर्फाइज़ किया जा सकता है ताकि कोई भी डिक्शनरी पॉइंटर (इंटरफ़ेस के लिए) रनटाइम पर फ़ंक्शन में पास न हो (मोनोमोर्फिज़ेशन जो मुझे लगता है कि गो कंपाइलर वर्तमान में इंटरफेस पर लागू होता है?) उपरोक्त उद्धरण में 'मान' से, मुझे लगता है कि उसका मतलब इनपुट प्रकार टी है, न कि टाइप टी द्वारा कार्यान्वित इंटरफ़ेस प्रकार के तरीकों का शब्दकोश।

यदि हम डेटा प्रकारों (जैसे struct ) पर टाइप पैरामीटर की अनुमति देते हैं, तो कहा गया है कि ऊपर टाइप टी को पैरामीटर किया जा सकता है, इसलिए हमारे पास वास्तव में एक प्रकार है T<U> । ऐसे प्रकार के कारखाने जिन्हें U के ज्ञान को बनाए रखने की आवश्यकता होती है, उन्हें उच्च प्रकार के प्रकार (HKT) कहा जाता है।

जेनरिक प्रकार-सुरक्षित बहुरूपी कंटेनरों की अनुमति देता है।

Cf भी _विषम_कंटेनरों के मुद्दे पर नीचे चर्चा की गई है। तो पॉलीमॉर्फिक से हमारा मतलब कंटेनर के मूल्य प्रकार (जैसे संग्रह का तत्व प्रकार) की सामान्यता से है, फिर भी यह मुद्दा भी है कि क्या हम एक से अधिक मूल्य प्रकार को एक साथ कंटेनर में रख सकते हैं जिससे वे विषम हो जाएं।

@tamird ने लिखा:

इन आवश्यकताओं को बाहर करने के लिए प्रतीत होता है जैसे कि रस्ट की विशेषता प्रणाली के समान एक प्रणाली, जहां सामान्य प्रकार विशेषता सीमा से विवश हैं।

रस्ट की विशेषता सीमा अनिवार्य रूप से टाइपक्लास सीमाएँ हैं।

@ एलेक्स ने लिखा:

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

आपको क्यों लगता है कि वे खराब फिट हैं? शायद आप उन विशेषता वस्तुओं के बारे में सोच रहे हैं जो रनटाइम प्रेषण को नियोजित करते हैं, इस प्रकार मोनोमोर्फिज्म से कम प्रदर्शनकारी होते हैं? लेकिन उन्हें टाइपक्लास सीमा सामान्यता सिद्धांत से अलग माना जा सकता है (सीएफ नीचे विषम कंटेनरों/संग्रह की मेरी चर्चा)। Afaics, Go के इंटरफेस पहले से ही विशेषता-जैसी सीमाएँ हैं और टाइपक्लास के लक्ष्य को पूरा करते हैं, जो देर से कॉल साइट पर डेटा प्रकारों के लिए शब्दकोशों को बाँधना है, बजाय OOP के एंटी-पैटर्न के जो जल्दी बाइंड करते हैं (भले ही अभी भी कंपाइल- समय) डेटा प्रकारों के लिए शब्दकोश (तत्काल/निर्माण पर)। टाइपक्लास (कम से कम डिग्री की स्वतंत्रता का आंशिक सुधार) अभिव्यक्ति समस्या को हल कर सकते हैं जो ओओपी नहीं कर सकता है।

@jimmyfrasche ने लिखा:

• https://golang.org/doc/faq#covariant_types

मैं उपरोक्त लिंक से सहमत हूं कि टाइपक्लास वास्तव में उप-टाइप नहीं कर रहे हैं और किसी विरासत संबंध को व्यक्त नहीं कर रहे हैं। और उपवर्ग के रूप में विरासत के साथ अनावश्यक रूप से "जेनेरिकिटी" (पैरामीट्रिक पॉलीमॉर्फिज्म की तुलना में पुन: उपयोग या मॉड्यूलरिटी की अधिक सामान्य अवधारणा के रूप में) का सामना नहीं करने के साथ सहमत हैं।

हालाँकि, मैं यह भी बताना चाहता हूँ कि यदि भाषा यूनियनों और चौराहों का समर्थन करती है, तो विरासत पदानुक्रम (उर्फ सबटाइपिंग) असाइनमेंट (फ़ंक्शन इनपुट) और (फ़ंक्शन आउटपुट) पर अपरिहार्य हैं, क्योंकि उदाहरण के लिए $#$ ⁰ int ν string int या string से असाइनमेंट स्वीकार कर सकते हैं लेकिन int ν string से असाइनमेंट स्वीकार नहीं कर सकते हैं। यूनियनों के बिना स्थिर रूप से टाइप किए गए विषम कंटेनर/संग्रह प्रदान करने के एकमात्र वैकल्पिक तरीके उप-वर्गीकरण या अस्तित्व में बंधे बहुरूपता (जंग में उर्फ ​​​​विशेषता वस्तुएं और हास्केल में अस्तित्वगत मात्रा का ठहराव) हैं। ऊपर दिए गए लिंक में अस्तित्व और यूनियनों के बीच ट्रेडऑफ़ के बारे में चर्चा है। अफैक, गो में विषम कंटेनर/संग्रह करने का एकमात्र तरीका अब सभी प्रकार को खाली interface{} में शामिल करना है जो टाइपिंग जानकारी को फेंक रहा है और क्या मुझे लगता है कि कास्ट और रनटाइम प्रकार निरीक्षण की आवश्यकता है, किस प्रकार का ² स्थिर टाइपिंग के बिंदु को हरा देता है।

बचने के लिए "एंटी-पैटर्न" उर्फ ​​वर्चुअल इनहेरिटेंस (cf भी "EDIT # 2" को अंतर्निहित सबमिशन और समानता, आदि के मुद्दों के बारे में) उप-वर्गीकृत कर रहा है।

¹ _{भले ही वे संरचनात्मक रूप से या नाममात्र रूप से मेल खाते हों क्योंकि सबटाइपिंग तुलनात्मक सेटों के आधार पर लिस्कोव प्रतिस्थापन सिद्धांत और रिटर्न वैल्यू के विपरीत फ़ंक्शन इनपुट के साथ असाइनमेंट की दिशा के कारण है, उदाहरण के लिए struct या interface का एक प्रकार पैरामीटर}

² _{निरपेक्षता लागू नहीं होगी क्योंकि हम असीमित गैर-नियतात्मकता के ब्रह्मांड की जांच टाइप नहीं कर सकते हैं। इसलिए जैसा कि मैं इसे समझता हूं, यह धागा सामान्यता के मुद्दों पर टाइपिंग wrt बताने के स्तर तक एक इष्टतम ("स्वीट स्पॉट") सीमा चुनने के बारे में है।}

@andrewcmyers ने लिखा:

Java और C# जेनरिक के विपरीत, Genus जेनरिक मैकेनिज्म सबटाइपिंग पर आधारित नहीं है।

यह इनहेरिटेंस और सबक्लासिंग ( स्ट्रक्चरल सबटाइपिंग नहीं ) है जो सबसे खराब एंटी-पैटर्न है जिसे आप जावा, स्काला, सीलोन और सी ++ ( सी ++ टेम्प्लेट के साथ समस्याओं से असंबंधित) से कॉपी नहीं करना चाहते हैं।

@thwd ने लिखा:

पैरामीटरयुक्त प्रकारों की जटिलता माप पर घातांक विचरण है। गो के प्रकार (इंटरफ़ेस को छोड़कर) अपरिवर्तनीय हैं और इसे नियम रखा जा सकता है और रखा जाना चाहिए।

अपरिवर्तनीयता के साथ उप-टाइप करना सहप्रसरण की जटिलता की ओर ले जाता है। अपरिवर्तनीयता सबक्लासिंग के साथ कुछ समस्याओं को भी सुधारती है (उदाहरण के लिए Rectangle बनाम Square ) लेकिन अन्य नहीं (उदाहरण के लिए निहित सबमिशन, समानता, आदि)।

@bxqgit ने लिखा:

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

ध्यान दें कि स्कैला ओओपी, सबक्लासिंग, एफपी, जेनेरिक मॉड्यूल, एचकेटी, और टाइपक्लास ( implicit के माध्यम से) को एक पीएल में मर्ज करने का प्रयास करता है। शायद अकेले टाइपक्लास पर्याप्त हो सकते हैं।

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

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

Afaics, Go_ में _Type Parameters के सिमेंटिक्स सेक्शन में, @ianlancetaylor द्वारा सामना की गई समस्या एक अवधारणात्मक समस्या है क्योंकि वह (afaics) जाहिरा तौर पर अनजाने में टाइपक्लास को फिर से खोज रहा है:

क्या हम दोनों दुनिया के सर्वश्रेष्ठ होने के लिए SortableSlice और PSortableSlice को मर्ज कर सकते हैं? काफी नहीं; एक पैरामीटरयुक्त फ़ंक्शन लिखने का कोई तरीका नहीं है जो Less विधि या एक बिल्टिन प्रकार के साथ किसी प्रकार का समर्थन करता है। समस्या यह है कि SortableSlice.Less को Less विधि के बिना किसी प्रकार के लिए तत्काल नहीं किया जा सकता है, और कुछ प्रकार के लिए केवल एक विधि को तुरंत चालू करने का कोई तरीका नहीं है, लेकिन अन्य नहीं।

[]T के लिए Less पद्धति पर टाइपक्लास बाउंड (भले ही कंपाइलर द्वारा अनुमानित रूप से अनुमान लगाया गया हो) के लिए requires Less[T] क्लॉज []T T पर है न कि []T । प्रत्येक T के लिए Less[T] टाइपक्लास (जिसमें एक विधि Less विधि शामिल है) का कार्यान्वयन या तो विधि के फ़ंक्शन बॉडी में कार्यान्वयन प्रदान करेगा या < असाइन करेगा U[T] की आवश्यकता होती है यदि Sortable[U] के तरीकों को एक प्रकार के पैरामीटर की आवश्यकता होती है U कार्यान्वयन प्रकार का प्रतिनिधित्व करता है, उदाहरण के लिए []T । अफेयर @keean के पास T मूल्य प्रकार के लिए एक अलग टाइपक्लास को नियोजित करने वाले प्रकार को संरचित करने का एक और तरीका है जिसके लिए एचकेटी की आवश्यकता नहीं होती है।

ध्यान दें कि []T के लिए वे विधियां Sortable[U] टाइपक्लास को कार्यान्वित कर रही हैं, जहां U []T है।

(तकनीकी एक तरफ: ऐसा लग सकता है कि हम SortableSlice और PSortableSlice को कुछ प्रकार के तर्कों के लिए एक विधि को तुरंत चालू करने के लिए कुछ तंत्र के द्वारा विलय कर सकते हैं, लेकिन अन्य नहीं। हालांकि, परिणाम संकलन का त्याग करना होगा -टाइम टाइप सुरक्षा, गलत प्रकार का उपयोग करने से रनटाइम पैनिक हो जाएगा। गो में पहले से ही इंटरफ़ेस प्रकार और विधियों का उपयोग कर सकते हैं और रनटाइम पर व्यवहार का चयन करने के लिए टाइप कर सकते हैं। टाइप पैरामीटर का उपयोग करके ऐसा करने के लिए कोई अन्य तरीका प्रदान करने की आवश्यकता नहीं है ।)

कॉल साइट पर बाध्य टाइपक्लास का चयन स्थिर रूप से ज्ञात T के लिए संकलन-समय पर हल किया जाता है। यदि विषम गतिशील प्रेषण की आवश्यकता है तो उन विकल्पों को देखें जिन्हें मैंने अपनी पिछली पोस्ट में समझाया था।

मुझे उम्मीद है कि @keean यहां आने के लिए समय निकाल सकते हैं और टाइपक्लास को समझाने में मदद कर सकते हैं क्योंकि वह अधिक विशेषज्ञ हैं और मुझे इन अवधारणाओं को सीखने में मदद मिली है। मेरे स्पष्टीकरण में कुछ त्रुटियाँ हो सकती हैं।

उन लोगों के लिए पीएस नोट जो पहले से ही मेरी पिछली पोस्ट पढ़ चुके हैं, ध्यान दें कि मैंने इसे पोस्ट करने के लगभग 10 घंटे बाद (कुछ नींद के बाद) बड़े पैमाने पर संपादित किया ताकि उम्मीद है कि विषम कंटेनरों के बारे में अधिक सुसंगत हो।

साइकिल अनुभाग गलत प्रतीत होता है। एक struct के S[T]{e} इंस्टेंस के रनटाइम निर्माण का जेनेरिक फ़ंक्शन के कार्यान्वयन के चयन से कोई लेना-देना नहीं है। वह संभवतः सोच रहा है कि संकलक नहीं जानता कि क्या यह तर्कों के प्रकार के लिए सामान्य कार्य के कार्यान्वयन में विशेषज्ञता प्राप्त कर रहा है, लेकिन उन सभी प्रकारों को संकलन-समय पर जाना जाता है।

एक एकीकरण एल्गोरिथ्म के लिए नोड्स के रूप में अलग-अलग प्रकार के कनेक्टेड ग्राफ़ की @ कीन की अवधारणा का अध्ययन करके शायद टाइप चेकिंग सेक्शन विनिर्देश को सरल बनाया जा सकता है। किनारे से जुड़े किसी भी विशिष्ट प्रकार में समरूप प्रकार होना चाहिए, किनारों के साथ किसी भी प्रकार के लिए बनाए गए जो असाइनमेंट के माध्यम से या स्रोत कोड में अन्यथा जुड़ते हैं। यदि मिलन और चौराहा है (मेरी पिछली पोस्ट से), तो असाइनमेंट की दिशा को ध्यान में रखना होगा ( किसी तरह? ) प्रत्येक विशिष्ट अज्ञात प्रकार शीर्ष की कम से कम ऊपरी सीमा (एलयूबी) और नीचे की सबसे बड़ी निचली सीमा ( जीएलबी ) से शुरू होता है और फिर बाधाएं इन सीमाओं को बदल सकती हैं। कनेक्टेड प्रकारों में संगत सीमाएं होनी चाहिए। बाधाएं सभी टाइपक्लास सीमाएं होनी चाहिए।

कार्यान्वयन में:

उदाहरण के लिए, प्रत्येक इंस्टेंटेशन के लिए फ़ंक्शन की एक नई प्रतिलिपि बनाकर पैरामीटरयुक्त फ़ंक्शंस को कार्यान्वित करना हमेशा संभव होता है, जहां प्रकार पैरामीटर को प्रकार तर्कों के साथ बदलकर नया फ़ंक्शन बनाया जाता है।

मेरा मानना ​​है कि सही तकनीकी शब्द मोनोमोर्फिज़ेशन है।

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

प्रोफाइलिंग प्रोग्रामर को बताएगी कि मोनोमोर्फिज़ेशन से कौन से फ़ंक्शन सबसे अधिक लाभान्वित हो सकते हैं। शायद जावा हॉटस्पॉट ऑप्टिमाइज़र रनटाइम पर मोनोमोर्फिज़ेशन ऑप्टिमाइज़ेशन करता है?

@egonelbre ने लिखा:

गो जेनरिक चर्चाओं का सारांश है , जो विभिन्न स्थानों से चर्चाओं का एक सिंहावलोकन प्रदान करने का प्रयास करता है।

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

समस्याओं में: सामान्य डेटा संरचना अनुभाग:

दोष

• जेनेरिक संरचनाएं सभी उपयोगों से सुविधाओं को जमा करती हैं, जिसके परिणामस्वरूप संकलन समय या कोड ब्लोट बढ़ जाता है या एक बेहतर लिंकर की आवश्यकता होती है।

टाइपक्लास के लिए यह या तो सच नहीं है या किसी मुद्दे से कम नहीं है, क्योंकि इंटरफेस को केवल उन डेटा प्रकारों के लिए लागू करने की आवश्यकता होती है जो उन इंटरफेस का उपयोग करने वाले कार्यों के लिए आपूर्ति की जाती हैं। टाइपक्लास इंटरफ़ेस के कार्यान्वयन के देर से बाध्यकारी हैं, ओओपी के विपरीत जो class कार्यान्वयन के लिए प्रत्येक डेटा प्रकार को इसके तरीकों से बांधता है।

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

• सामान्य संरचनाएं और उन पर काम करने वाले एपीआई उद्देश्य-निर्मित एपीआई की तुलना में अधिक सारगर्भित होते हैं, जो कॉल करने वालों पर संज्ञानात्मक बोझ डाल सकते हैं

एक काउंटर तर्क जो मुझे लगता है कि इस चिंता को काफी हद तक सुधारता है, वह यह है कि अनिवार्य रूप से समान सामान्य एल्गोरिदम के विशेष मामले के पुन: कार्यान्वयन की असीमित संख्या सीखने का संज्ञानात्मक बोझ असीमित है। जबकि, अमूर्त जेनेरिक एपीआई सीखना सीमित है।

• गहन अनुकूलन बहुत गैर-सामान्य और संदर्भ विशिष्ट हैं, इसलिए उन्हें सामान्य एल्गोरिदम में अनुकूलित करना कठिन है।

यह एक वैध कॉन नहीं है। 80/20 नियम कहता है कि कोड के लिए असीमित जटिलता (जैसे समयपूर्व अनुकूलन) न जोड़ें, जब प्रोफाइल की आवश्यकता नहीं होती है। प्रोग्रामर 20% मामलों में अनुकूलन करने के लिए स्वतंत्र है, जबकि शेष 80% सामान्य एपीआई की सीमित जटिलता और संज्ञानात्मक भार से नियंत्रित होते हैं।

हम वास्तव में यहां जो प्राप्त कर रहे हैं वह एक भाषा की नियमितता और सामान्य एपीआई सहायता है, इससे चोट नहीं लगती है। उन विपक्ष वास्तव में सही ढंग से अवधारणा नहीं कर रहे हैं।

वैकल्पिक समाधान:

• जटिल संरचनाओं के बजाय सरल संरचनाओं का उपयोग करें
  
  
  
  • उदाहरण के लिए सेट के बजाय मानचित्र [int] संरचना {} का उपयोग करें
  
  

रॉब पाइक (और मैंने उसे वीडियो में उस बिंदु को बनाते हुए भी देखा) ऐसा लगता है कि जेनेरिक कंटेनर सामान्य कार्य करने के लिए पर्याप्त नहीं हैं। हमें T में map[T] की आवश्यकता है ताकि हम इनपुट, आउटपुट और अपने स्वयं के struct के कार्यों में सामान्य डेटा प्रकार को पास कर सकें। केवल कंटेनर प्रकार के मापदंडों पर जेनरिक जेनेरिक एपीआई को व्यक्त करने के लिए पूरी तरह से अपर्याप्त है और जेनेरिक एपीआई को सीमित जटिलता और संज्ञानात्मक भार और एक भाषा पारिस्थितिकी तंत्र में नियमितता प्राप्त करने के लिए आवश्यक है। इसके अलावा, मैंने रिफैक्टरिंग के बढ़े हुए स्तर को नहीं देखा है (इस प्रकार मॉड्यूल की कम संगतता जिसे आसानी से दोबारा नहीं किया जा सकता है) कि गैर-जेनेरिक कोड की आवश्यकता होती है, जो कि अभिव्यक्ति समस्या है जिसके बारे में मैंने अपनी पहली पोस्ट में उल्लेख किया है।

सामान्य दृष्टिकोण अनुभाग में:

पैकेज टेम्पलेट्स
यह मोडुला -3, OCaml, SML (तथाकथित "फ़ंक्टर"), और Ada द्वारा उपयोग किया जाने वाला एक दृष्टिकोण है। विशेषज्ञता के लिए एक व्यक्तिगत प्रकार निर्दिष्ट करने के बजाय, पूरा पैकेज सामान्य है। आप आयात करते समय प्रकार के मापदंडों को ठीक करके पैकेज को विशेषज्ञ बनाते हैं।

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

बल्कि मेरी समझ यह है कि वह पैकेज (उर्फ मॉड्यूल) प्रकार पैरामीट्रिजेशन struct , interface , और func के समूह में प्रकार पैरामीटर लागू करने की क्षमता को सक्षम बनाता है।

अधिक जटिल प्रकार-प्रणाली
हास्केल और रस्ट इस दृष्टिकोण को अपनाते हैं।
[…]
दोष:

• सरल भाषा में फिट होना मुश्किल है (https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ)

लिंक किए गए दस्तावेज़ में @ianlancetaylor का हवाला देते हुए:

यदि आप ऐसा मानते हैं, तो यह इंगित करने योग्य है कि मूल
गो रनटाइम में मैप और स्लाइस कोड के अर्थ में सामान्य नहीं है
बहुरूपता प्रकार का उपयोग करना। यह इस अर्थ में सामान्य है कि यह दिखता है
कैसे स्थानांतरित करें और तुलना करें यह देखने के लिए प्रतिबिंब जानकारी टाइप करें
मूल्य। तो हमारे पास अस्तित्व से प्रमाण है कि लिखना स्वीकार्य है
टाइप . का उपयोग करने वाले गैर-पॉलीमॉर्फिक कोड लिखकर गो में "जेनेरिक" कोड
परावर्तन जानकारी कुशलता से, और फिर उस कोड को लपेटने के लिए
कंपाइल-टाइम टाइप-सेफ बॉयलरप्लेट (नक्शे और स्लाइस के मामले में)
यह बॉयलर प्लेट, निश्चित रूप से, संकलक द्वारा प्रदान की जाती है)।

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

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

हाँ, यह मेरे दिमाग में एक विचार रहा है कि क्या पूर्ण विकसित टाइपक्लास सिस्टम में जाना उचित है। यदि आपके सभी पुस्तकालय इसके आसपास आधारित हैं, तो जाहिर तौर पर यह एक सुंदर सामंजस्य हो सकता है, लेकिन अगर हम सामान्यता के लिए मौजूदा गो हैक्स की जड़ता के बारे में विचार कर रहे हैं, तो शायद प्राप्त अतिरिक्त तालमेल बहुत सारी परियोजनाओं के लिए कम होने वाला है। ?

लेकिन अगर एक टाइपक्लास सिंटैक्स से एक ट्रांसपिलर मौजूदा मैनुअल तरीके का अनुकरण करता है तो गो जेनरिक मॉडल कर सकता है (संपादित करें: जिसे मैंने अभी पढ़ा है कि @andrewcmyers स्टेट्स प्रशंसनीय है ), यह कम कठिन हो सकता है और उपयोगी तालमेल ढूंढ सकता है। उदाहरण के लिए, मुझे एहसास हुआ कि दो पैरामीटर टाइपक्लास को interface के साथ अनुकरण किया जा सकता है जो $ struct #$ पर लागू होता है जो एक टपल का अनुकरण करता है, या @jba ने संदर्भ में इनलाइन interface को नियोजित करने के लिए एक विचार का उल्लेख किया है . स्पष्ट रूप से struct नाममात्र टाइप किए जाने के बजाय संरचनात्मक रूप से टाइप किए जाते हैं जब तक कि type के साथ कोई नाम नहीं दिया जाता है? इसके अलावा, मैंने एक interface की एक विधि की पुष्टि की है जो एक और interface इनपुट कर सकती है, इसलिए यह संभव है कि एचकेटी से आपके प्रकार के उदाहरण में ट्रांसपाइल करना संभव हो, मैंने अपनी पिछली पोस्ट में यहां लिखा था। लेकिन मुझे इस बारे में और सोचने की जरूरत है जब मुझे इतनी नींद नहीं आ रही है।

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

मुझे संदेह है कि कोई असहमत होगा! मोनोमोर्फिज़ेशन लाभ ट्यूरिंग पूर्ण जेनेरिक मेटाप्रोग्रामिंग इंजन के डाउनसाइड्स के लिए ऑर्थोगोनल है।

बीटीडब्ल्यू, सी ++ टेम्पलेट्स की डिज़ाइन त्रुटि मुझे जेनरेटिव (आवेदक के विपरीत) एमएल फ़ैक्टर के दोष का एक ही उत्पादक सार प्रतीत होता है । न्यूनतम शक्ति का सिद्धांत लागू होता है।

@ianlancetaylor ने लिखा:

बिल्ट-इन पैरामीटरयुक्त प्रकारों को जोड़कर गो को अधिक से अधिक जटिल होते हुए देखना निराशाजनक है।

इस मुद्दे में अटकलों के बावजूद, मुझे लगता है कि ऐसा होने की संभावना बहुत कम है।

मुझे आशा है। मेरा दृढ़ विश्वास है कि गो को या तो एक सुसंगत जेनेरिक सिस्टम जोड़ना चाहिए या बस यह स्वीकार करना चाहिए कि इसमें कभी भी जेनरिक नहीं होगा।

मुझे लगता है कि एक ट्रांसपिलर के लिए एक कांटा होने की अधिक संभावना है, आंशिक रूप से क्योंकि मेरे पास इसे लागू करने के लिए धन है और मुझे ऐसा करने में दिलचस्पी है। फिर भी मैं अभी भी स्थिति का विश्लेषण कर रहा हूं।

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

@pciet ने लिखा:

मेरा वोट सामान्यीकृत एप्लिकेशन जेनरिक के लिए नहीं है, हाँ append और copy जैसे अधिक अंतर्निहित सामान्य कार्यों के लिए जो कई आधार प्रकारों पर काम करते हैं। शायद sort और search संग्रह प्रकारों के लिए जोड़ा जा सकता है?

इस जड़ता का विस्तार शायद एक व्यापक जेनेरिक सुविधा को इसे कभी भी गो में बनाने से रोकेगा। जो लोग जेनरिक चाहते थे, उनके हरियाली वाले चरागाहों की ओर जाने की संभावना है। @andrewcmyers ने इसे दोहराया:

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

@ शेल्बी3

अफैक, गो में विषम कंटेनर/संग्रह करने का एकमात्र तरीका अब सभी प्रकारों को एक खाली इंटरफ़ेस {} में शामिल करना है जो टाइपिंग जानकारी को फेंक रहा है और क्या मुझे लगता है कि कास्ट और रनटाइम प्रकार निरीक्षण की आवश्यकता है, जो प्रकार 2 के बिंदु को हरा देता है स्थिर टाइपिंग।

गो में इंटरफ़ेस {} संग्रह की स्थिर प्रकार की जांच के लिए उपरोक्त टिप्पणियों में रैपर पैटर्न देखें।

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

क्या आप इसे और समझा सकते हैं? संग्रह प्रकार के मामले में निहित वस्तुओं के आवश्यक सामान्य व्यवहार को परिभाषित करने वाला इंटरफ़ेस होने के लिए कार्यों को लिखना उचित लगता है।

@pciet यह कोड सचमुच सटीक काम कर रहा है @ shelby3 एक एंटीपैटर्न का वर्णन और विचार कर रहा था। आपको पहले से उद्धृत करना:

यह प्रलेखन और परीक्षण उदाहरणों में देता है जो संकलन-समय प्रकार की सुरक्षा के लिए रैपर पैटर्न (धन्यवाद @pierrre) टाइप करते हैं और रन-टाइम प्रकार की सुरक्षा के लिए प्रतिबिंबित जांच भी करते हैं।

आप कोड ले रहे हैं जिसमें टाइप जानकारी की कमी है और टाइप-बाय-टाइप आधार पर, रिफ्लेक्ट का उपयोग करके कास्ट और रनटाइम टाइप इंस्पेक्शन जोड़ रहे हैं। यह वही है जो @ शेल्बी 3 शिकायत कर रहा था। मैं इस दृष्टिकोण को "मोनोमोर्फिज़ेशन-बाय-हैंड" कहता हूं और वास्तव में एक कठिन काम है जो मुझे लगता है कि एक कंपाइलर के लिए सबसे अच्छा है।

इस दृष्टिकोण के कई नुकसान हैं:

• टाइप-बाय-टाइप रैपर की आवश्यकता होती है, जिसे या तो हाथ से बनाए रखा जाता है या go generate -जैसे टूल
• (यदि उपकरण के बजाय हाथ से किया जाता है) बॉयलरप्लेट में गलतियाँ करने का अवसर जो रनटाइम तक नहीं पकड़ा जाएगा
• स्थैतिक प्रेषण के बजाय गतिशील प्रेषण की आवश्यकता होती है, जो धीमा है और अधिक मेमोरी का उपयोग करता है
• संकलन-समय प्रकार के अभिकथनों के बजाय रनटाइम प्रतिबिंब का उपयोग करता है, जो धीमा भी है
• कंपोज़ेबल नहीं: पूरी तरह से ठोस प्रकारों पर कार्य करता है, जिसमें टाइपक्लास-जैसी (या यहां तक ​​​​कि इंटरफ़ेस-जैसी) सीमाओं का उपयोग करने का कोई अवसर नहीं होता है, जब तक कि आप प्रत्येक गैर-खाली इंटरफ़ेस के लिए संकेत की एक और परत को नियंत्रित नहीं करना चाहते हैं, जिसे आप अमूर्त करना चाहते हैं

क्या आप इसे और समझा सकते हैं? संग्रह प्रकार के मामले में निहित वस्तुओं के आवश्यक सामान्य व्यवहार को परिभाषित करने वाला इंटरफ़ेस होने के लिए कार्यों को लिखना उचित लगता है।

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

ऐसे विचार भी हैं, जहां तक ​​मुझे पता है, गो के टाइप सिस्टम में आज बिल्कुल भी व्यक्त नहीं किया जा सकता है, जैसे कि इंटरफेस के संयोजन पर बाध्य। कल्पना कीजिए कि हमारे पास है:

type Foo interface {
    ...
}

type Bar interface {
    ...
}

हम विशुद्ध रूप से स्थिर प्रकार की जाँच का उपयोग करके कैसे व्यक्त करते हैं, कि हम एक ऐसा प्रकार चाहते हैं जो Foo और Bar दोनों को लागू करता हो? जहां तक ​​​​मुझे पता है कि यह गो में संभव नहीं है (रनटाइम चेक का सहारा लेने की कमी जो विफल हो सकती है, स्थिर प्रकार की सुरक्षा से बचकर)।

टाइपक्लास-आधारित जेनरिक प्रणाली के साथ हम इसे इस प्रकार व्यक्त कर सकते हैं:

func baz<T Foo + Bar>(t T) {
    ...
}

@tarcieri

पूरी तरह से स्थिर प्रकार की जांच का उपयोग करके हम कैसे व्यक्त करते हैं कि हम एक ऐसा प्रकार चाहते हैं जो फू और बार दोनों को लागू करे?

बस ऐसे ही:

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinet साफ, TIL

व्यक्तिगत रूप से मैं रनटाइम प्रतिबिंब को एक गलत विशेषता मानता हूं, लेकिन यह सिर्फ मैं हूं... अगर किसी को दिलचस्पी है तो मैं इसमें जा सकता हूं।

मुझे लगता है कि किसी भी प्रकार के जेनरिक को लागू करने वाले किसी भी व्यक्ति को स्टेपानोव के "एलिमेंट्स ऑफ प्रोग्रामिंग" को पहले कई बार पढ़ना चाहिए। यह बहुत सारी नॉट इनवेंटेड हियर समस्याओं और पहिया को फिर से आविष्कार करने से बचाएगा। इसे पढ़ने के बाद यह स्पष्ट होना चाहिए कि क्यों "सी++ कॉन्सेप्ट्स" और "हास्केल टाइपक्लासेस" जेनरिक करने का सही तरीका है।

मैं देख रहा हूं कि यह मुद्दा फिर से सक्रिय लगता है
यहाँ एक स्ट्रोमैन प्रस्ताव खेल का मैदान है
https://go-li.github.io/test.html
यहाँ से सिर्फ डेमो प्रोग्राम पेस्ट करें
https://github.com/go-li/demo

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

हम हैक किए गए gccgo को बनाए रखते हैं और
यह परियोजना आपके बिना असंभव होगी, इसलिए हम
वापस योगदान देना चाहता था।

इसके अलावा, हम आशा करते हैं कि आप जो भी जेनरिक अपनाते हैं, बढ़िया काम करते रहें!

@anlhord इसके बारे में कार्यान्वयन विवरण कहां हैं? वाक्य रचना के बारे में कोई कहाँ पढ़ सकता है? क्या लागू किया जाता है? क्या लागू नहीं किया गया है? इस कार्यान्वयन के लिए विनिर्देश क्या हैं? इसके पक्ष और विपक्ष क्या हैं?

खेल के मैदान के लिंक में इसका सबसे खराब संभावित उदाहरण है:

package main

import "fmt"

func main() {
    fmt.Println("Hello, playground")
}

वह कोड मुझे कुछ नहीं बताता कि इसका उपयोग कैसे करना है और मैं क्या परीक्षण कर सकता हूं।

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

आशा है कि इससे आपको अपनी टिप्पणी के साथ समस्याओं को समझने में मदद मिली होगी।

@ जोहो ने लिखा:

क्या दृष्टिकोणों के मूल्यांकन पर किसी मार्गदर्शन के लिए अकादमिक साहित्य का कोई महत्व होगा?

इस विषय पर मैंने जो एकमात्र पेपर पढ़ा है, वह यह है कि क्या डेवलपर्स को सामान्य प्रकारों से लाभ होता है ? (पेवॉल सॉरी, आप गूगल पर एक पीडीएफ डाउनलोड कर सकते हैं) जिसमें निम्नलिखित कहने के लिए था

नतीजतन, प्रयोग की एक रूढ़िवादी व्याख्या
यह है कि सामान्य प्रकारों को ट्रेडऑफ़ के रूप में माना जा सकता है
सकारात्मक प्रलेखन विशेषताओं और के बीच
नकारात्मक एक्स्टेंसिबिलिटी विशेषताओं।

मुझे लगता है कि ओओपी और सबक्लासिंग (जैसे जावा और सी ++ में कक्षाएं) दोनों को गंभीरता से नहीं माना जाएगा क्योंकि गो में पहले से ही टाइपक्लास जैसा interface है (स्पष्ट T जेनेरिक प्रकार पैरामीटर के बिना), जावा है उद्धृत किया गया है कि क्या कॉपी नहीं करना है, और क्योंकि कई लोगों ने तर्क दिया है कि वे एक विरोधी पैटर्न हैं। अपथ्रेड मैंने उस तर्क में से कुछ से लिंक किया है। अगर कोई दिलचस्पी लेता है तो हम उस विश्लेषण में गहराई से जा सकते हैं।

मैंने अभी तक नए शोध का अध्ययन नहीं किया है जैसे कि जीनस सिस्टम ने अपथ्रेड का उल्लेख किया है । मैं "रसोई सिंक" सिस्टम से सावधान हूं जो स्कैला के बारे में शिकायतों के कारण इतने सारे प्रतिमानों (उदाहरण के लिए उप-वर्गीकरण, एकाधिक विरासत, ओओपी, विशेषता रैखिकरण, implicit , टाइपक्लास, अमूर्त प्रकार, आदि) को मिश्रित करने का प्रयास करता है। अभ्यास में इतने सारे कोने के मामले हैं, हालांकि शायद यह स्कैला 3 (उर्फ डॉटी और डीओटी कैलकुस) के साथ बेहतर होगा। मैं उत्सुक हूं कि उनकी तुलना तालिका प्रयोगात्मक स्कैला 3 या स्कैला के वर्तमान संस्करण की तुलना कर रही है?

तो ठीक है, सिद्ध जेनेरिकिटी सिस्टम के संदर्भ में एमएल फ़ैक्टर और हास्केल टाइपक्लास क्या हैं, जो ओओपी + सबक्लासिंग की तुलना में एक्स्टेंसिबिलिटी और लचीलेपन में काफी सुधार करते हैं।

मैंने कुछ निजी चर्चा @keean लिखी और मेरे पास ML फ़ैक्टर मॉड्यूल बनाम टाइपक्लास के बारे में था। हाइलाइट्स प्रतीत होते हैं:

• टाइपक्लास _मॉडल एक बीजगणित_ (लेकिन बिना चेक किए गए स्वयंसिद्धों के ) और प्रत्येक इंटरफ़ेस के लिए प्रत्येक डेटा प्रकार को केवल एक ही तरीके से लागू करें। इस प्रकार कॉल साइट पर एनोटेशन के बिना संकलक द्वारा कार्यान्वयन के निहित चयन को सक्षम करना।

• एप्लिकेटिव फंक्शनलर्स में रेफरेंशियल ट्रांसपेरेंसी होती है जबकि जेनरेटिव फंक्शनल प्रत्येक इंस्टेंटेशन पर एक नया इंस्टेंस बनाते हैं, जिसका मतलब है कि वे इनिशियलाइज़ेशन ऑर्डर इनवेरिएंट नहीं हैं।

• ML फ़ैक्टर टाइपक्लास की तुलना में अधिक शक्तिशाली/लचीले होते हैं लेकिन यह अधिक एनोटेशन और संभावित रूप से अधिक कॉर्नर केस इंटरैक्शन की कीमत पर आता है। और @keean के अनुसार उन्हें आश्रित प्रकार ( संबंधित प्रकारों के लिए) की आवश्यकता होती है जो कि अधिक जटिल प्रकार की प्रणाली है। @कीन सोचता है कि स्टेपानोव की _अभिव्यक्ति एक बीजगणित_ प्लस टाइपक्लास के रूप में पर्याप्त शक्तिशाली और लचीलापन है , इसलिए यह अत्याधुनिक, अच्छी तरह से सिद्ध (हास्केल में और अब जंग में) सामान्यता के लिए मीठा स्थान प्रतीत होता है। हालांकि, सिद्धांतों को टाइपक्लास द्वारा लागू नहीं किया जाता है।

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

@larsth ने लिखा:

एक या एक से अधिक प्रयोगात्मक ट्रांसपिलर रखना दिलचस्प हो सकता है - गो 1.xy स्रोत कोड कंपाइलर के लिए एक सामान्य जेनेरिक स्रोत कोड।

_{पीएस मुझे संदेह है कि गो इस तरह के एक परिष्कृत टाइपिंग सिस्टम को अपनाएगा, लेकिन मैं मौजूदा गो सिंटैक्स के लिए एक ट्रांसपिलर पर विचार कर रहा हूं जैसा कि मैंने अपनी पिछली पोस्ट में उल्लेख किया है (नीचे संपादन देखें)। और मैं उन बहुत ही वांछनीय गो सुविधाओं के साथ एक मजबूत सामान्य प्रणाली चाहता हूं। गो पर टाइपक्लास जेनरिक वही प्रतीत होता है जो मैं चाहता हूं।}

@bcmills ने सामान्यता के लिए संकलन-समय के कार्यों के बारे में अपने प्रस्ताव के बारे में लिखा:

मैंने सुना है कि गो एपीआई में ठोस प्रकारों के बजाय interface प्रकार के निर्यात के लिए वकालत करने के लिए एक ही तर्क का उपयोग किया जाता है, और रिवर्स अधिक सामान्य हो जाता है: समयपूर्व अमूर्तता एपीआई के प्रकार और बाधा के विस्तार को रोकता है। (ऐसे एक उदाहरण के लिए, #19584 देखें।) यदि आप तर्क की इस पंक्ति पर भरोसा करना चाहते हैं तो मुझे लगता है कि आपको कुछ ठोस उदाहरण प्रदान करने की आवश्यकता है।

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

सामान्यता के लिए एक प्रणाली को डिजाइन करते समय, हम संभवतः पारिस्थितिकी तंत्र की नियमितता और पूर्वानुमेयता को सिद्धांत लक्ष्यों में से एक के रूप में बढ़ाना चाहते हैं, खासकर यदि गो के मूल दर्शन को ध्यान में रखा जाता है (उदाहरण के लिए औसत प्रोग्रामर प्राथमिकता हैं)।

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

निश्चित रूप से, लेकिन यह किसी भी सामान्य प्रोग्रामिंग तंत्र से स्वतंत्र गो में निहित बाधाओं के लिए पहले से ही सच है।

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

लेकिन afaik Go ने उन प्रभावों को संशोधित करने के लिए एक अमूर्त डिजाइन करने का प्रयास नहीं किया। जंग में ऐसा अमूर्तता है (जो मुझे लगता है कि बीटीडब्ल्यू कुछ/अधिकांश उपयोग मामलों के लिए पिटा/त्सुरिस/सीमित है और मैं एक आसान सिंगल-थ्रेडेड मॉडल अबास्ट्रक्शन के लिए तर्क देता हूं, दुर्भाग्य से गो सभी स्पॉन्डेड गोरोइन को एक ही थ्रेड पर प्रतिबंधित करने का समर्थन नहीं करता है ) . और हास्केल को संदर्भात्मक पारदर्शिता के लिए शुद्ध कार्यों को लागू करने के कारण प्रभावों पर मोनैडिक नियंत्रण की आवश्यकता होती है।

@alercah ने लिखा:

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

माना। अन्य मॉड्यूल में कोड को गुप्त रूप से तोड़ने में सक्षम होने के कारण प्रकार के इनवेरिएंट को स्पष्ट रूप से एनोटेट नहीं किया जाता है, यह गंभीर रूप से कपटी है।

@andrewcmyers ने लिखा:

स्पष्ट होने के लिए, मैं मैक्रो-स्टाइल कोड जनरेशन पर विचार नहीं करता, चाहे वह gen, cpp, gofmt -r, या अन्य मैक्रो/टेम्पलेट टूल्स के साथ किया गया हो, जेनेरिक समस्या का एक अच्छा समाधान होने के लिए, भले ही मानकीकृत हो। इसमें सी ++ टेम्प्लेट जैसी ही समस्याएं हैं: कोड ब्लोट, मॉड्यूलर टाइप चेकिंग की कमी और डिबगिंग में कठिनाई। जैसे ही आप शुरू करते हैं, यह और भी खराब हो जाता है, जैसा कि स्वाभाविक है, अन्य सामान्य कोड के संदर्भ में सामान्य कोड बनाना। मेरे दिमाग में, फायदे सीमित हैं: यह गो कंपाइलर लेखकों के लिए जीवन को अपेक्षाकृत सरल बनाए रखेगा और यह कुशल कोड उत्पन्न करता है - जब तक कि निर्देश कैश दबाव न हो, आधुनिक सॉफ़्टवेयर में लगातार स्थिति!

@keean आपसे सहमत प्रतीत होता है।

@ शेल्बी 3 टिप्पणियों के लिए धन्यवाद। क्या आप अगली बार सीधे दस्तावेज़ में ही टिप्पणियाँ/संपादन कर सकते हैं। यह ट्रैक करना आसान है कि चीजों को कहाँ ठीक करना है और यह सुनिश्चित करना आसान है कि सभी नोटों को उचित प्रतिक्रिया मिले।

अवलोकन खंड का अर्थ यह प्रतीत होता है कि जावा के उदाहरणों के लिए मुक्केबाजी संदर्भों का सार्वभौमिक उपयोग ...

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

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

यह कथन इस बारे में है कि दीर्घावधि में सामान्य डेटा-संरचनाओं का क्या होता है। दूसरे शब्दों में, एक सामान्य डेटा-संरचना अक्सर विभिन्न उद्देश्यों के लिए कई छोटे कार्यान्वयन होने के बजाय सभी अलग-अलग उपयोगों को एकत्रित करती है। एक उदाहरण के रूप में https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html देखें।

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

सामान्य संरचनाएं और उन पर काम करने वाले एपीआई उद्देश्य-निर्मित एपीआई की तुलना में अधिक सारगर्भित होते हैं ...

एक काउंटर तर्क जो मुझे लगता है कि इस चिंता को काफी हद तक बढ़ाता है, वह यह है कि अनिवार्य रूप से समान सामान्य एल्गोरिदम के विशेष मामले के पुन: कार्यान्वयन की असीमित संख्या सीखने का संज्ञानात्मक बोझ असीमित है ...

कई समान एपीआई के संज्ञानात्मक भार के बारे में एक नोट जोड़ा गया।

विशेष मामले के पुन: कार्यान्वयन व्यवहार में असीमित नहीं हैं। आप केवल एक निश्चित संख्या में विशेषज्ञता देखेंगे।

यह एक वैध कॉन नहीं है।

आप कुछ बिंदुओं से असहमत हो सकते हैं, मैं उनमें से कुछ से कुछ हद तक असहमत हूं, लेकिन मैं उनके दृष्टिकोण को समझता हूं और उन समस्याओं को समझने की कोशिश करता हूं जिनका लोग दिन-प्रतिदिन सामना करते हैं। दस्तावेज़ का लक्ष्य अलग-अलग राय एकत्र करना है, न कि "किसी के लिए कुछ कितना कष्टप्रद है" का न्याय करना।

हालाँकि, दस्तावेज़ "वास्तविक-विश्व-समस्याओं के लिए पता लगाने योग्य समस्याओं" पर एक रुख अपनाता है, क्योंकि मंचों में अमूर्त और सुगम समस्याएं बिना किसी समझ के बिना अर्थहीन बकबक में उतर जाती हैं।

हम वास्तव में यहां जो प्राप्त कर रहे हैं वह एक भाषा की नियमितता और सामान्य एपीआई सहायता है, इससे चोट नहीं लगती है।

निश्चित रूप से व्यवहार में आपको केवल 1% से कम मामलों के लिए अनुकूलन की इस शैली की आवश्यकता हो सकती है।

वैकल्पिक समाधान:

वैकल्पिक समाधान जेनरिक के विकल्प के रूप में नहीं हैं। बल्कि, विभिन्न प्रकार की समस्याओं के संभावित समाधानों की एक सूची।

पैकेज टेम्पलेट्स

मुझसे गलती हो सकती है लेकिन यह बिल्कुल सही नहीं लगता। एमएल फ़ैक्टर (एफपी फ़ैक्टर के साथ भ्रमित नहीं होने के लिए) एक आउटपुट भी वापस कर सकते हैं जो कि पैरामीट्रिज्ड टाइप रहता है।

क्या आप एक स्पष्ट शब्द प्रदान कर सकते हैं और यदि आवश्यक हो तो दो अलग-अलग दृष्टिकोणों में विभाजित कर सकते हैं?

@egonelbre प्रतिक्रिया देने के लिए भी धन्यवाद ताकि मैं जान सकूं कि मुझे किन बिंदुओं पर अपने विचारों को और स्पष्ट करने की आवश्यकता है।

क्या आप अगली बार सीधे दस्तावेज़ में ही टिप्पणियाँ/संपादन कर सकते हैं।

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

एक उदाहरण के रूप में https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html देखें।

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

मैं "रसोई सिंक" प्रणालियों से सावधान हूं जो स्कैला के बारे में शिकायतों के कारण इतने सारे प्रतिमानों (उदाहरण के लिए उप-वर्गीकरण, एकाधिक विरासत, ओओपी, विशेषता रैखिकरण, implicit , टाइपक्लास, अमूर्त प्रकार, आदि) को मिश्रित करने का प्रयास करते हैं। अभ्यास में इतने सारे कोने के मामले हैं, हालांकि शायद यह स्कैला 3 (उर्फ डॉटी और डीओटी कैलकुस) के साथ बेहतर होगा।

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

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

इसके लिए अच्छे निर्देशों की भी जरूरत है, चीजों का उपयोग कैसे किया जाना चाहिए और किन चीजों से बचना चाहिए, और इस बात पर विचार करें कि लोग इसका उपयोग कैसे करते हैं।

और मुझे लगता है कि यह प्रोग्रामर के लिए एक ही भाषा में उपलब्ध कई अलग-अलग प्रतिमानों को मिलाने में मदद नहीं करेगा। यह स्पष्ट रूप से आवश्यक नहीं है ( @keean और मुझे उस दावे को साबित करने की आवश्यकता है)। मुझे लगता है कि हम दोनों इस दर्शन को मानते हैं कि जटिलता बजट सीमित है और यह वही है जो आप पीएल से बाहर छोड़ते हैं जो कि सुविधाओं के रूप में महत्वपूर्ण है।

हालाँकि, दस्तावेज़ "वास्तविक-विश्व-समस्याओं के लिए पता लगाने योग्य समस्याओं" पर एक रुख अपनाता है, क्योंकि मंचों में अमूर्त और सुगम समस्याएं बिना किसी समझ के बिना अर्थहीन बकबक में उतर जाती हैं।

माना। और सभी के लिए अमूर्त बिंदुओं का पालन करना भी कठिन है। जंगली में शैतान विवरण और वास्तविक परिणामों में है।

निश्चित रूप से व्यवहार में आपको केवल 1% से कम मामलों के लिए अनुकूलन की इस शैली की आवश्यकता हो सकती है।

सामान्यता के लिए गो के पास पहले से ही interface है, ताकि कॉल साइट द्वारा आपूर्ति किए गए इंटरफ़ेस के उदाहरण के लिए T प्रकार पर पैरामीट्रिक बहुरूपता की आवश्यकता न होने वाले मामलों को संभाल सके।

मुझे लगता है कि कहीं पढ़ा है, शायद यह अपथ्रेड था, यह तर्क कि वास्तव में गो का मानक पुस्तकालय सबसे अद्यतन मुहावरों के इष्टतम उपयोग की असंगति से पीड़ित है। मुझे नहीं पता कि क्या यह सच है, क्योंकि मुझे अभी तक गो के साथ अनुभव नहीं हुआ है। मैं जो बिंदु बना रहा हूं वह यह है कि चुने गए जेनरिक प्रतिमान सभी पुस्तकालयों को संक्रमित करते हैं। तो हाँ अभी तक आप दावा कर सकते हैं कि केवल 1% कोड की आवश्यकता होगी, क्योंकि मुहावरों में पहले से ही जड़ता है जो जेनरिक की आवश्यकता से बचते हैं।

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

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

क्या आप एक स्पष्ट शब्द प्रदान कर सकते हैं और यदि आवश्यक हो तो दो अलग-अलग दृष्टिकोणों में विभाजित कर सकते हैं?

मैं उन लोगों के लिए अपनी आवाज जोड़ता हूं जो गो में कुछ अत्यधिक सरलीकृत टेम्पलेटिंग सुविधा डालने के प्रयास को हतोत्साहित करना चाहते हैं और दावा करते हैं कि यह जेनेरिक है। IOW, मुझे लगता है कि एक उचित कामकाजी जेनरिक प्रणाली जो खराब जड़ता को समाप्त नहीं करेगी, जेनरिक के लिए अत्यधिक सरलीकृत डिजाइन की इच्छा के साथ मौलिक रूप से असंगत है। अफैक, एक जेनेरिक प्रणाली के लिए एक सुविचारित और अच्छी तरह से सिद्ध समग्र डिजाइन की आवश्यकता होती है। @larsth ने जो लिखा है, उसकी प्रतिध्वनि करते हुए, मैं गंभीर प्रस्तावों वाले लोगों को पहले एक ट्रांसपिलर बनाने (या gccgo फ्रंटएंड के एक कांटे में लागू करने) के लिए प्रोत्साहित करता हूं और फिर प्रस्ताव के साथ प्रयोग करता हूं ताकि हम सभी इसकी सीमाओं को बेहतर ढंग से समझ सकें। मुझे अपथ्रेड पढ़ने के लिए प्रोत्साहित किया गया था कि @ianlancetaylor ने नहीं सोचा था कि गो में खराब जड़ता का प्रदूषण जोड़ा जाएगा। जहां तक ​​पैकेज स्तर के पैरामीट्रिजेशन प्रस्ताव के बारे में मेरी विशिष्ट शिकायत का सवाल है, मेरे सुझाव के लिए जो कभी भी इसे प्रस्तावित कर रहा है, कृपया विचार करें कि क्या एक कंपाइलर बनाना है जिसे हम सभी के साथ खेलने के लिए उपयोग कर सकते हैं और फिर हम सभी उदाहरणों के बारे में बात कर सकते हैं कि हमें क्या पसंद है और क्या नहीं। टी इसके बारे में पसंद है। अन्यथा, हम एक दूसरे के पीछे बात कर रहे हैं क्योंकि शायद मैं संक्षेप में वर्णित प्रस्ताव को सही ढंग से समझ भी नहीं पा रहा हूं। मुझे प्रस्ताव को नहीं समझना चाहिए, क्योंकि मुझे समझ में नहीं आता कि कैसे पैरामीट्रिज्ड पैकेज को दूसरे पैकेज में पुन: उपयोग किया जा सकता है जो पैरामीट्रिज्ड भी है। IOW, यदि कोई पैकेज पैरामीटर लेता है, तो उसे पैरामीटर के साथ अन्य पैकेजों को भी तुरंत चालू करने की आवश्यकता होती है। लेकिन ऐसा लग रहा था कि प्रस्ताव यह बता रहा था कि पैरामीट्रिज्ड पैकेज को इंस्टेंट करने का एकमात्र तरीका एक ठोस प्रकार था, न कि टाइप पैरामीटर।

माफी इतनी लंबी हवा। मैं यह सुनिश्चित करना चाहता हूं कि मुझे गलत नहीं समझा गया है।

@ शेल्बी 3 आह, मैंने तब प्रारंभिक शिकायत को गलत समझा। पहले मुझे यह स्पष्ट करना चाहिए कि "जेनेरिक दृष्टिकोण" के खंड ठोस प्रस्ताव नहीं हैं। वे दृष्टिकोण हैं या, दूसरे शब्दों में, बड़े डिजाइन निर्णय जो एक ठोस जेनेरिक दृष्टिकोण में ले सकते हैं। हालांकि, समूह मौजूदा कार्यान्वयन या ठोस/अनौपचारिक प्रस्तावों से दृढ़ता से प्रेरित होते हैं। साथ ही, मुझे संदेह है कि उस सूची से कम से कम 5 बड़े विचार अभी भी गायब हैं।

"पैकेज टेम्प्लेट" दृष्टिकोण के लिए इसके दो रूप हैं (दस्तावेज़ में लिंक की गई चर्चा देखें):

1. "इंटरफ़ेस" आधारित सामान्य पैकेज,
2. स्पष्ट रूप से सामान्य पैकेज।

1 के लिए इसे कुछ विशेष करने के लिए सामान्य पैकेज की आवश्यकता नहीं है - उदाहरण के लिए वर्तमान container/ring विशेषज्ञता के लिए प्रयोग योग्य हो जाएगा। पैकेज में इंटरफ़ेस के सभी उदाहरणों को ठोस प्रकार (और परिपत्र आयात को अनदेखा करने) के साथ बदलने के रूप में यहां "विशेषज्ञता" की कल्पना करें। जब वह पैकेज स्वयं किसी अन्य पैकेज में विशेषज्ञता रखता है, तो वह "इंटरफ़ेस" को विशेषज्ञता के रूप में उपयोग कर सकता है - यह इस प्रकार है कि यह उपयोग भी विशिष्ट होगा।

2 के लिए आप उन्हें दो तरह से देख सकते हैं। प्रत्येक आयात पर एक पुनरावर्ती ठोस विशेषज्ञता है - टेम्पलेटिंग/मैक्रोइंग के समान, किसी भी समय "आंशिक रूप से लागू पैकेज" नहीं होगा। बेशक इसे कार्यात्मक पक्ष से भी देखा जा सकता है, कि सामान्य पैकेज पैरामीटर के साथ आंशिक है और फिर आप इसे विशेषज्ञ बनाते हैं।

तो, हाँ, आप दूसरे में एक पैरामीटरयुक्त पैकेज का उपयोग कर सकते हैं।

@larsth ने जो लिखा है, उसकी प्रतिध्वनि करते हुए, मैं गंभीर प्रस्तावों वाले लोगों को पहले एक ट्रांसपिलर बनाने (या gccgo फ्रंटएंड के एक कांटे में लागू करने) के लिए प्रोत्साहित करता हूं और फिर प्रस्ताव के साथ प्रयोग करता हूं ताकि हम सभी इसकी सीमाओं को बेहतर ढंग से समझ सकें।

मुझे पता है कि यह उस दृष्टिकोण पर स्पष्ट रूप से निर्देशित नहीं था, लेकिन इस विचार का परीक्षण करने के लिए इसमें 4 अलग-अलग प्रोटोटाइप हैं। बेशक, वे पूर्ण ट्रांसपिलर नहीं हैं, लेकिन वे कुछ विचारों का परीक्षण करने के लिए पर्याप्त हैं। यानी मुझे यकीन नहीं है कि किसी ने "दूसरे से पैरामीटरयुक्त पैकेज का उपयोग करके" मामले को लागू किया है या नहीं।

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

जनरेटिव पैकेज दृष्टिकोण के साथ समस्या यह है कि यह बहुत सारे बॉयलरप्लेट बनाता है, जहां आप पैरामीटर के साथ संकुल को तत्काल कर रहे हैं। यह कैसा दिखता है यह देखने के लिए आप एडा जेनरिक देख सकते हैं।

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

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

सटीक शब्दावली के लिए धन्यवाद, मुझे यह सोचने की ज़रूरत है कि इन विचारों को दस्तावेज़ में कैसे एकीकृत किया जाए।

साथ ही, मुझे कोई कारण नहीं दिख रहा है कि आपके पास "जेनरेट किए गए पैकेज में स्वचालित प्रकार-उपनाम" क्यों नहीं हो सकता है - एक अर्थ में "आवेदक मज़ेदार" और "जेनरेटिव फ़ैक्टर" दृष्टिकोण के बीच कुछ। जाहिर है, जब पैकेज में राज्य का कोई रूप होता है, तो इसे डीबग करना और समझना जटिल हो सकता है।

जनरेटिव पैकेज दृष्टिकोण के साथ समस्या यह है कि यह बहुत सारे बॉयलरप्लेट बनाता है, जहां आप पैरामीटर के साथ संकुल को तत्काल कर रहे हैं। यह कैसा दिखता है यह देखने के लिए आप एडा जेनरिक देख सकते हैं।

जहां तक ​​​​मैं देखता हूं, यह सी ++ टेम्पलेट्स की तुलना में कम बॉयलरप्लेट बनाएगा लेकिन टाइप-क्लास से ज्यादा। क्या आपके पास एडा के लिए एक अच्छा वास्तविक-विश्व कार्यक्रम है जो समस्या को प्रदर्शित करता है? _(असली दुनिया से, मेरा मतलब उस कोड से है जो कोई उत्पादन में उपयोग कर रहा है।)_

ज़रूर, मेरे एडा गो-बोर्ड पर एक नज़र डालें: https://github.com/keean/Go-Board-Ada/blob/master/go.adb

हालांकि यह उत्पादन की एक काफी ढीली परिभाषा है, कोड अनुकूलित है, साथ ही साथ सी ++ संस्करण, और इसके ओपन-सोर्स का प्रदर्शन करता है, और एल्गोरिदम को कई वर्षों में परिष्कृत किया गया है। आप C++ संस्करण को भी देख सकते हैं: https://github.com/keean/Go-Board/blob/master/go.cpp

यह दिखाता है (मुझे लगता है) कि एडीए जेनरिक सी ++ टेम्पलेट्स (लेकिन यह मुश्किल नहीं है) की तुलना में एक साफ समाधान है, दूसरी तरफ संदर्भ लौटने पर प्रतिबंधों के कारण एडा में डेटा संरचनाओं तक तेजी से पहुंच करना मुश्किल है। .

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

हालांकि मुझे लगता है कि टाइपक्लास के कुछ फायदे हैं, मैं एडा स्टाइल जेनरिक के साथ रह सकता हूं, कुछ ऐसे मुद्दे हैं जो मुझे एडा का अधिक व्यापक रूप से उपयोग करने से रोकते हैं, मुझे लगता है कि यह मूल्य/वस्तुओं को गलत करता है (मुझे लगता है कि बहुत कम भाषाओं को यह अधिकार मिलता है, 'सी' केवल उनमें से एक है), पॉइंटर्स (एक्सेस वेरिएबल्स) के साथ काम करना और सुरक्षित-पॉइंटर एब्स्ट्रैक्शन बनाना मुश्किल है, और यह रनटाइम-पॉलीमॉर्फिज्म के साथ पैकेज का उपयोग करने का एक तरीका प्रदान नहीं करता है (यह एक ऑब्जेक्ट मॉडल प्रदान करता है इसके लिए, लेकिन यह पैकेजों का उपयोग करके रनटाइम-पॉलिमॉर्फिज्म का तरीका खोजने की कोशिश करने के बजाय एक नया प्रतिमान जोड़ता है)।

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

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

@ कीन ने लिखा :

व्यक्तिगत रूप से मैं रनटाइम प्रतिबिंब को एक गलत विशेषता मानता हूं, लेकिन यह सिर्फ मैं हूं... अगर किसी को दिलचस्पी है तो मैं इसमें जा सकता हूं।

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

मैंने अपथ्रेड भी कहा था:

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

@ कीन ने लिखा:

[...] एक पैकेज के लागू होने के लिए यह शुद्ध होना चाहिए (जो कि पैकेज स्तर पर कोई परिवर्तनशील चर नहीं है)

और अपरिवर्तनीय चर प्रारंभ करने के लिए कोई अशुद्ध कार्य नियोजित नहीं किया जा सकता है।

@egonelbre ने लिखा:

तो, हाँ, आप दूसरे में एक पैरामीटरयुक्त पैकेज का उपयोग कर सकते हैं।

मेरे मन में स्पष्ट रूप से "प्रथम श्रेणी के पैरामीट्रिज्ड पैकेज" और अनुरूप रनटाइम (उर्फ डायनेमिक) पॉलीमॉर्फिज्म था, जिसका बाद में @keean ने उल्लेख किया है, क्योंकि मुझे लगता है कि पैरामीट्रिज्ड पैकेज टाइपक्लास या ओओपी के बदले प्रस्तावित किए गए थे।

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

@ कीन ने लिखा:

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

आश्रित प्रकारों से आप क्या समझते हैं ? (संपादित करें: मुझे लगता है कि अब उनका मतलब "गैर-मूल्य-निर्भर" टाइपिंग है, यानी " फ़ंक्शंस जिसका परिणाम प्रकार [रनटाइम?] तर्क ['s प्रकार] पर निर्भर करता है") निश्चित रूप से मूल्यों पर निर्भर नहीं है उदाहरण के लिए int डेटा, जैसे इदरीस में। मुझे लगता है कि आप कॉल पदानुक्रम के नीचे तत्काल मॉड्यूल उदाहरणों का प्रतिनिधित्व करने वाले मानों के प्रकार पर निर्भर रूप से टाइपिंग (यानी ट्रैकिंग) का जिक्र कर रहे हैं ताकि ऐसे पॉलिमॉर्फिक कार्यों को संकलन-समय पर मोनोमोर्फिक किया जा सके? क्या ऐसे मोनोमोर्फिज्ड प्रकारों के गतिशील प्रकारों के लिए बाध्य अस्तित्व प्रकार होने के कारण रनटाइम पॉलीमॉर्फिज्म प्रवेश करता है? F-ing मॉड्यूल ने प्रदर्शित किया कि सिस्टम F में ML मॉड्यूल की मॉडलिंग के लिए " _{आश्रित} " प्रकार बिल्कुल आवश्यक नहीं हैं। अगर मुझे लगता है कि @rossberg ने सभी मोनोमोर्फिज़ेशन आवश्यकताओं को दूर करने के लिए टाइपिंग मॉडल में सुधार किया है, तो क्या मैंने इसकी देखरेख की है?

जनरेटिव पैकेज दृष्टिकोण के साथ समस्या यह है कि यह बहुत सारे बॉयलरप्लेट बनाता है […]
टाइप क्लास केवल फ़ंक्शन में उपयोग किए जाने वाले प्रकारों के आधार पर टाइपक्लास का चयन करके इस बॉयलरप्लेट से बचते हैं।

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

टाइपक्लास केवल प्रत्येक प्रकार को एक तरह से लागू कर सकते हैं और अन्यथा सीमा को पार करने के लिए newtype रैपर बॉयलरप्लेट की आवश्यकता होती है। एल्गोरिदम को लागू करने के कई तरीकों का एक और उदाहरण यहां दिया गया है। Afaics, @keean ने स्पष्ट रूप से चयनित Relation के साथ निहित चयन को ओवरराइड करके अपने टाइपक्लास सॉर्ट उदाहरण में इस सीमा के आसपास काम किया, मूल्य प्रकार पर सामान्य रूप से अलग-अलग संबंधों को नाम देने के लिए रैपिंग data प्रकारों को नियोजित किया, लेकिन मुझे संदेह है क्या ऐसी रणनीति प्रतिरूपकता के सभी प्रकारों के लिए सामान्य है। हालाँकि एक अधिक सामान्यीकृत समाधान (जो वैश्विक विशिष्टता की प्रतिरूपकता समस्या को सुधारने में सहायता कर सकता है, संभवतः एक अनाथ प्रतिबंध के साथ संयुक्त रूप से अनाथ समाधान के लिए प्रस्तावित संस्करण में सुधार के रूप में कार्यान्वयन के लिए एक गैर-डिफ़ॉल्ट को नियोजित करके जो अनाथ हो सकता है) हो सकता है अतिरिक्त प्रकार पैरामीटर सभी टाइपक्लास interface पर निहित है, जो सामान्य निहित मिलान के लिए डिफ़ॉल्ट निर्दिष्ट नहीं है, लेकिन जब निर्दिष्ट किया जाता है (या निर्दिष्ट नहीं होने पर किसी अन्य ² से मेल नहीं खाता है) तो समान मूल्य वाले कार्यान्वयन का चयन करता है कस्टम मानों की अल्पविराम-सीमांकित सूची में (इसलिए यह एक विशिष्ट implement उदाहरण के नामकरण की तुलना में अधिक सामान्यीकृत, मॉड्यूलर मिलान है)। अल्पविराम-सीमांकित सूची इसलिए है कि एक कार्यान्वयन को एक से अधिक डिग्री-स्वतंत्रता में विभेदित किया जा सकता है, जैसे कि इसमें दो ऑर्थोगोनल विशेषज्ञताएं हैं। वांछित गैर-डिफ़ॉल्ट विशेष को फ़ंक्शन घोषणा या कॉल साइट पर निर्दिष्ट किया जा सकता है। कॉल साइट पर, जैसे f<non-default>(…) ।

तो अगर हमारे पास टाइपक्लास हैं तो हमें पैरामीट्रिज्ड मॉड्यूल की आवश्यकता क्यों होगी? Afaics केवल (← महत्वपूर्ण लिंक क्लिक करने के लिए) प्रतिस्थापन के लिए क्योंकि उस उद्देश्य के लिए टाइपक्लास का पुन: उपयोग करना इसमें अच्छी तरह से फिट नहीं होता है उदाहरण के लिए हम चाहते हैं कि एक पैकेज मॉड्यूल कई फाइलों को फैलाने में सक्षम हो और हम सामग्री को स्पष्ट रूप से खोलने में सक्षम होना चाहते हैं तो शायद एक _सिंटैक्टिकल-केवल_ प्रतिस्थापन-केवल (प्रथम श्रेणी नहीं) पैकेज पैरामीट्रिजेशन के साथ आगे बढ़ना उचित पहला कदम है जो मॉड्यूल-स्तर की सामान्यता को संबोधित कर सकता है जबकि कार्यक्षमता के साथ संगतता के लिए खुला रहता है और फ़ंक्शन-स्तर के लिए बाद में टाइपक्लास जोड़ने पर कार्यक्षमता का गैर-ओवरलैप होता है उदारता। मैक्रोज़ उदाहरण के लिए टाइप किए गए हैं या केवल वाक्य-विन्यास (उर्फ "प्रीप्रोसेसर") प्रतिस्थापन हैं। यदि टाइप किया गया है, तो मॉड्यूल टाइपक्लास की कार्यक्षमता को डुप्लिकेट करते हैं, जो पीएल के ओवरलैपिंग प्रतिमानों/अवधारणाओं को कम करने के दृष्टिकोण से अवांछनीय है और ओवरलैप के इंटरैक्शन के कारण संभावित कोने के मामले (जैसे कि एमएल फ़ैक्टर और टाइपक्लास दोनों की पेशकश करने का प्रयास करते समय) ) टाइप किए गए मॉड्यूल अधिक मॉड्यूलर होते हैं क्योंकि मॉड्यूल के भीतर किसी भी इनकैप्सुलेटेड कार्यान्वयन में संशोधन जो निर्यात किए गए हस्ताक्षर को संशोधित नहीं करता है, मॉड्यूल के उपभोक्ताओं को असंगत नहीं बना सकता है (टाइपक्लास ओवरलैपिंग कार्यान्वयन उदाहरणों की उपरोक्त एंटी-मॉड्यूलरिटी समस्या के अलावा)। मुझे इस पर @ कीन के विचार पढ़ने में दिलचस्पी है।

[…] पॉलीमॉर्फिक रिकर्सन और अस्तित्वगत प्रकारों के अपवादों के साथ (जो अनिवार्य रूप से ऐसे रूप हैं जिन्हें आप बाहर नहीं कर सकते हैं, आप केवल उन इंटरफेस का उपयोग कर सकते हैं जिनकी पुष्टि संस्करण करता है)।

अन्य पाठकों की मदद करने के लिए। "पॉलीमॉर्फिक रिकर्सन" द्वारा, मुझे लगता है कि उच्च-रैंक वाले प्रकारों को संदर्भित करता है, उदाहरण के लिए रनटाइम पर सेट पैरामीट्रिज्ड कॉलबैक जहां कंपाइलर कॉलबैक फ़ंक्शन के शरीर को मोनोमोर्फाइज नहीं कर सकता क्योंकि यह संकलन-समय पर ज्ञात नहीं है। अस्तित्व के प्रकार हैं जैसा कि मैंने रस्ट की विशेषता वस्तुओं के बराबर पहले उल्लेख किया है, जो कि विषम कंटेनरों को प्राप्त करने का एक तरीका है जो बाद में अभिव्यक्ति समस्या में class उपवर्ग आभासी विरासत की तुलना में बाध्यकारी है, लेकिन अभिव्यक्ति में विस्तार के लिए खुला नहीं है अपरिवर्तनीय डेटा संरचनाओं के साथ यूनियनों के रूप में समस्या या ³ की प्रतिलिपि बनाना जिसमें ओ (लॉग एन) प्रदर्शन लागत है ।

¹ _{जिसे उपरोक्त उदाहरण में HKT की आवश्यकता नहीं है, क्योंकि SET की आवश्यकता नहीं है elem प्रकार सामान्य प्रकार के set का एक प्रकार पैरामीटर है, अर्थात यह set<elem> नहीं है}

² _{फिर भी यदि एक से अधिक गैर-डिफ़ॉल्ट कार्यान्वयन मौजूद हैं और कोई डिफ़ॉल्ट कार्यान्वयन नहीं है, तो चयन अस्पष्ट होगा इसलिए संकलक को एक त्रुटि उत्पन्न करनी चाहिए।}

³ _{अपरिवर्तनीय डेटा संरचनाओं के साथ परिवर्तन नोट के लिए आवश्यक रूप से संपूर्ण डेटा संरचना की प्रतिलिपि बनाने की आवश्यकता नहीं होती है, यदि डेटा संरचना एकल-लिंक्ड सूची जैसे इतिहास को अलग करने के लिए पर्याप्त स्मार्ट है।}

func pick(a CollectionOfT, count uint) []T को लागू करना जेनरिक का एक अच्छा उदाहरण अनुप्रयोग होगा (https://github.com/golang/go/issues/23717 से):

// pick returns a slice (len = n) of pseudorandomly chosen elements 
// in unspecified order from c which is an array, slice, or map.
for i, e := range pick(c, n) {

यहां इंटरफ़ेस {} दृष्टिकोण जटिल है।

मैंने इस मुद्दे पर कुछ बार टिप्पणी की है कि सी ++ टेम्पलेट दृष्टिकोण के साथ प्रमुख समस्याओं में से एक संकलन-समय मेटाप्रोग्रामिंग के लिए तंत्र के रूप में ओवरलोड रिज़ॉल्यूशन पर निर्भरता है।

ऐसा लगता है कि हर्ब सटर एक ही निष्कर्ष पर आया है: सी ++ में संकलन-समय प्रोग्रामिंग के लिए अब एक दिलचस्प प्रस्ताव है ।

इसमें गो reflect पैकेज और गो में संकलन-समय कार्यों के लिए मेरे पहले के प्रस्ताव दोनों के साथ कुछ तत्व समान हैं।

नमस्ते।
मैंने गो के लिए बाधाओं के साथ जेनरिक के लिए एक प्रस्ताव लिखा है। आप इसे यहां पढ़ सकते हैं। शायद इसे 15292 के दस्तावेज़ के रूप में जोड़ा जा सकता है। यह ज्यादातर बाधाओं के बारे में है और इसे टेलर्स टाइप पैरामीटर्स इन गो में संशोधन के रूप में पढ़ा जाता है।
यह गो में 'टाइप सेफ' जेनरिक करने के एक व्यावहारिक (मेरा मानना ​​​​है) तरीके के उदाहरण के रूप में है, - उम्मीद है कि यह इस चर्चा में कुछ जोड़ सकता है।
कृपया ध्यान दें, जबकि मैंने इस बहुत लंबे धागे को (अधिकांश) पढ़ा है, मैंने इसमें सभी लिंक का पालन नहीं किया है, इसलिए अन्य लोगों ने भी इसी तरह के सुझाव दिए होंगे। अगर ऐसा है तो मैं माफी मांगता हूं।

बीआर Chr.

सिंटैक्स बाइकशेडिंग:

constraint[T] Array {
    :[#]T
}

हो सकता है

type [T] Array constraint {
    _ [...]T
}

जो अधिक लगता है मेरे पास जाओ। :-)

यहां कई तत्व।

एक चीज़ : को _ से बदल रही है और # को ... से बदल रही है।
मुझे लगता है कि अगर आप इसे पसंद करते हैं तो आप ऐसा कर सकते हैं।

एक और चीज constraint[T] Array को type[T] Array constraint से बदल रही है।
ऐसा प्रतीत होता है कि बाधाएं प्रकार हैं, जो मुझे नहीं लगता कि यह सही है। औपचारिक रूप से, एक बाधा सभी प्रकार के सेट पर एक _predicate_ है, अर्थात। प्रकार के सेट से सेट के लिए एक मैपिंग { true , false }।
या यदि आप पसंद करते हैं, तो आप एक बाधा के बारे में सोच सकते हैं जैसे कि _a प्रकार का सेट।
यह _a_ प्रकार नहीं है।

बीआर Chr.

वह constraint सिर्फ एक interface क्यों नहीं है?

type [T io.Writer] List struct { 
    element T; 
    next *List[T];
}

निम्नलिखित प्रस्ताव के साथ बाधा के रूप में एक इंटरफ़ेस थोड़ा अधिक उपयोगी होगा: # 23796 जो बदले में प्रस्ताव को कुछ योग्यता भी देगा।

साथ ही, यदि योग प्रकारों का प्रस्ताव किसी रूप (#19412) में स्वीकार किया जाता है, तो उनका उपयोग प्रकार को सीमित करने के लिए किया जाना चाहिए।

हालांकि मेरा मानना ​​​​है कि बाधा कीवर्ड, बड़ी बाधाओं को दोहराने और अनुपस्थिति के कारण त्रुटियों को रोकने के लिए कुछ ऐसा जोड़ा जाना चाहिए।

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

// similar to the map[T]... syntax
// also no constraint
type List[T] struct {
    element T
    next *List[T]
}

// with constraint
type List[T] struct {
    element T
    next *List[T]
} where T is io.Writer | encoding.BinaryMarshaler

type BigConstraint constraint {
     io.Writer
     SomeFunc() int
     AnotherFunc()
     AField int64
     StringField string
}


// with predefined constraint
type List[T, U] struct {
    element T
    val U
    next *List[T, U]
} where T is BigConstraint | encoding.BinaryMarshaler,
    U is io.Reader

@urandom : मुझे लगता है कि स्पष्ट रूप से इंटरफेस को स्पष्ट रूप से लागू करने के लिए जाने के लिए इसका एक बड़ा फायदा है। इस टिप्पणी में @surlykke प्रस्ताव मुझे लगता है कि आत्मा में अन्य गो सिंटैक्स के बहुत करीब है।

@surlykke मैं क्षमा चाहता हूं यदि प्रस्ताव में इनमें से किसी का उत्तर है।

जेनरिक का उपयोग अंतर्निहित शैली कार्यों की अनुमति देना है। आप इसके साथ एप्लिकेशन-लेवल लेन कैसे लागू करेंगे? प्रत्येक अनुमत इनपुट के लिए मेमोरी लेआउट अलग है, तो यह इंटरफ़ेस से बेहतर कैसे है?

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

संग्रह एक और उपयोग है:

// An unordered collection of comparable items.
type [T Comparable] Set []T

func (a Set) Diff(from Set) Set {
    // the implementation is the same as one with
    //     type Comparable interface { Equal(Comparable) bool }
    //     type Set []Comparable
}

// compile error
d := Set[int]{1, 2}.Diff(Set[string]{“abc”, “def”})

// Go 1, easier to read but runtime error
d := Set{1, 2}.Diff(Set{“abc”, “def”})

संग्रह प्रकार के मामले के लिए मुझे विश्वास नहीं है कि यह गो 1 जेनरिक पर एक बड़ी जीत है क्योंकि पठनीयता ट्रेडऑफ़ हैं।

मैं सहमत हूं कि टाइप पैरामीटर में कुछ प्रकार की बाधाएं होनी चाहिए। अन्यथा हम C++ टेम्प्लेट की गलतियों को दोहराते रहेंगे। सवाल यह है कि बाधाएं कितनी अभिव्यंजक होनी चाहिए?

एक छोर पर, हम सिर्फ इंटरफेस का उपयोग कर सकते थे। लेकिन जैसा कि आप इंगित करते हैं, इस तरह से बहुत से उपयोगी पैटर्न कैप्चर नहीं किए जा सकते हैं।

फिर आपका विचार है, और इसी तरह के, जो उपयोगी बाधाओं का एक सेट तैयार करने का प्रयास करते हैं और उन्हें व्यक्त करने के लिए नया वाक्यविन्यास प्रदान करते हैं। अभी और सिंटैक्स जोड़ने की समस्या के अलावा, यह स्पष्ट नहीं है कि कहाँ रुकना है। जैसा कि आप इंगित करते हैं, आपका प्रस्ताव कई पैटर्नों को ग्रहण करता है, लेकिन किसी भी तरह से सभी नहीं।

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

@jba
यह थोड़ा वर्बोज़ है। हो सकता है कि अगर गो में लैम्ब्डा सिंटैक्स होता तो यह थोड़ा अधिक स्वादिष्ट होता। दूसरी ओर, ऐसा लगता है कि यह सबसे बड़ी समस्या है जिसे हल करने का प्रयास कर रहा है यह जांच रहा है कि कोई प्रकार किसी प्रकार के ऑपरेटर का समर्थन करता है या नहीं। यह आसान हो सकता है यदि गो के पास विभिन्न ऑपरेटरों के लिए पूर्वनिर्धारित इंटरफेस हैं:

func equal[T](x, y T) bool
    where T is runtime.Equitable {
    return x == y
}

func copyable[T](x, y []T) int {
    return copy(x, y)
}

या इन पंक्तियों के साथ कुछ।

यदि समस्या विस्तारित बिलिन्स के साथ है, तो हो सकता है कि समस्या एडेप्टर प्रकार बनाने के भाषा के तरीके में निहित हो। उदाहरण के लिए, क्या ब्लोट सॉर्ट से जुड़ा नहीं है। https://github.com/golang/go/issues/16721 और सॉर्ट.स्लाइस के पीछे का पूरा कारण इंटरफ़ेस करें?
https://github.com/golang/go/issues/21670#issuecomment -325739411 को देखते हुए, @ सजमानी का इंटरफ़ेस शाब्दिक होने का विचार टाइप पैरामीटर के लिए आसानी से बिल्टिन के साथ काम करने के लिए आवश्यक घटक हो सकता है।
इटरेटर की निम्नलिखित परिभाषा को देखें:

type [T] Iterator interface {
    Next() (elem T, done bool)
}

यदि print एक ऐसा फ़ंक्शन है जो केवल एक सूची पर पुनरावृति करता है और इसकी सामग्री को प्रिंट करता है, तो निम्न उदाहरण print के लिए एक संतोषजनक इंटरफ़ेस बनाने के लिए इंटरफ़ेस शाब्दिक का उपयोग करता है।

func SliceIterator(slice []T) Iterator {
    i := 0
    return Iterator{
        Next: func() (elem int, done bool) {
            v := slice[i]
            if i+1 == len(slice) {
                return v, true
            }
            i++
            return v, false
        },
    }
}

func main() {
    arr := []int{1,2,3,4,5}
    // SliceIterator works for an arbitrary slice
    print(SliceIterator(arr))
}

कोई पहले से ही ऐसा कर सकता है यदि वे विश्व स्तर पर उन प्रकारों की घोषणा करते हैं जिनकी एकमात्र जिम्मेदारी एक इंटरफ़ेस को संतुष्ट करना है। हालांकि, एक फ़ंक्शन से एक विधि में यह रूपांतरण इंटरफेस (और इसलिए "बाधाओं") को संतुष्ट करने में आसान बनाता है। हम साधारण एडेप्टर (जैसे सॉर्टिंग में "widgetsByName") के साथ शीर्ष-स्तरीय घोषणाओं को प्रदूषित नहीं करते हैं।
उपयोगकर्ता-परिभाषित प्रकार स्पष्ट रूप से इस सुविधा का भी लाभ उठा सकते हैं, जैसा कि इस लिंक्डलिस्ट उदाहरण द्वारा देखा गया है:

type ListNode struct {
    v string
    next *ListNode
}
func (l *ListNode) Iterator() Iterator {
    ptr := l
    return Iterator{
        Next: func() (elem int, done bool) {
            v := ptr.v
            if ptr.next == nil {
                return v, true
            }
            ptr = ptr.next
            return v, false
        },
    }
}

@ geovanisouza92 : जैसा कि मैंने वर्णन किया है कि बाधाएं इंटरफेस (फ़ील्ड, ऑपरेटर) से अधिक अभिव्यक्तिपूर्ण हैं। मैंने संक्षेप में बाधाओं को पेश करने के बजाय इंटरफेस का विस्तार करने पर विचार किया था, लेकिन मुझे लगता है कि यह गो के मौजूदा तत्व में बहुत अधिक दखल देने वाला परिवर्तन होगा।

@pciet मुझे पूरा यकीन नहीं है कि 'आवेदन स्तर' से आपका क्या मतलब है। गो में एक अंतर्निहित len फ़ंक्शन है जिसे सरणी, पॉइंटर टू एरे, स्लाइस, स्ट्रिंग और चैनल पर लागू किया जा सकता है, इसलिए, मेरे प्रस्ताव में, यदि कोई प्रकार पैरामीटर इनमें से एक के लिए बाध्य है क्योंकि यह अंतर्निहित प्रकार है , len इस पर लागू किया जा सकता है।

@pciet आपके उदाहरण के बारे में Comparable बाधा/इंटरफ़ेस के साथ। ध्यान दें कि यदि आप परिभाषित करते हैं (इंटरफ़ेस संस्करण):

type Comparable interface { Equal(Comparable) bool }
type Set []Comparable

फिर आप Comparable को Set में लागू करने वाली कोई भी चीज़ डाल सकते हैं। इसकी तुलना करें:

constraint [T] Comparable { Equal(t T) bool }
type [T Comparable[T]] Set []T
...
type FooSet Set[Foo] // Where Foo satisfies constraint Comparable

जहां आप केवल Foo FooSet $#$ में डाल सकते हैं। वह मजबूत प्रकार की सुरक्षा है।

@urandom फिर से, मैं इसका प्रशंसक नहीं हूं:

type MyConstraint constraint {....}

जैसा कि मुझे विश्वास नहीं है कि एक स्थिरांक एक प्रकार है। इसके अलावा, मैं निश्चित रूप से इसकी अनुमति नहीं दूंगा:

var myVar MyConstraint

जो मुझे कोई मतलब नहीं है। एक और संकेत है कि बाधाएं प्रकार नहीं हैं।

@urandom बाइकशेडिंग पर: मेरा मानना ​​​​है कि प्रकार के मापदंडों के ठीक बगल में बाधाओं को घोषित किया जाना चाहिए। इस तरह परिभाषित एक सामान्य कार्य पर विचार करें:

func MyFunc(i) {
     if (i>0) fmt.Println("It's positive")
} with i being an integer

आप इसे बाएँ से दाएँ नहीं पढ़ सके। इसके बजाय आप यह निर्धारित करने के लिए पहले func MyFunc(i) पढ़ेंगे कि यह एक फ़ंक्शन परिभाषा है। फिर आपको यह पता लगाने के लिए अंत तक कूदना होगा कि i क्या है, और फिर फ़ंक्शन बॉडी पर वापस जाएं। आदर्श नहीं, आईएमओ। और मैं नहीं देखता कि कैसे सामान्य परिभाषाएं अलग होनी चाहिए।
लेकिन जाहिर है, यह चर्चा इस बारे में ऑर्थोगोनल है कि क्या गो में बाधाएं होनी चाहिए या जेनेरिक।

@surlykke
मैं ठीक हूं क्योंकि यह एक प्रकार का नहीं है। सबसे महत्वपूर्ण बात यह है कि उनका एक नाम है ताकि उन्हें कई प्रकार से संदर्भित किया जा सके।

कार्यों के लिए, यदि हम रस्ट सिंटैक्स का पालन करते हैं, तो यह होगा:

func MyFunc[I](i I) int64
     where I is being an integer {
   return 42
}

तो यह फ़ंक्शन के नाम या उसके पैरामीटर जैसी चीज़ों को नहीं छिपाएगा, और आपको यह देखने के लिए फ़ंक्शन बॉडी के अंत में जाने की आवश्यकता नहीं होगी कि सामान्य प्रकारों पर बाधा क्या है

भावी पीढ़ी के लिए @surlykke , क्या आप यह पता लगा सकते हैं कि आपका प्रस्ताव कहाँ जोड़ा जा सकता है:
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

यह सभी प्रस्तावों को "संकलित" करने के लिए एक शानदार जगह है।

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

क्या यह मान लेना सुरक्षित है कि जब कंपाइलर टाइप-पैरामीटर पर टाइप-स्विच देखता है, तो उसे प्रत्येक अभिकथन के लिए एक अलग कार्यान्वयन उत्पन्न करने की अनुमति होती है? या यह भी एक अनुकूलन में शामिल है, क्योंकि नेस्टेड प्रकार-पैरामीटर मुखर structs में कोड पीढ़ी के लिए एक पैरामीट्रिक पहलू बना सकते हैं?

संकलन-समय के कार्यों के प्रस्ताव में, क्योंकि हम जानते हैं कि ये घोषणाएं संकलन-समय पर उत्पन्न होती हैं, एक प्रकार-स्विच कोई रनटाइम लागत उत्पन्न नहीं करता है।

एक व्यावहारिक परिदृश्य: यदि हम गणित/बिट्स पैकेज के मामले पर विचार करते हैं, तो प्रत्येक uintXX $ के लिए OnesCount पर कॉल करने के लिए एक प्रकार-अभिकथन करना एक कुशल बिट-मैनिपुलेशन लाइब्रेरी होने की बात को हरा देगा। यदि हालांकि, प्रकार-दावे को निम्नलिखित में बदल दिया गया था

func OnesCount(x T) int {
    switch x.(type) {
    case uint:
        // separate uint functionality...
    case uint8:
        // separate uint8 functionality...
    case uint16:
        // separate uint16 functionality...
    case uint32:
        // separate uint32 functionality...
    case uint64:
        // separate uint64 functionality...
    }
}

एक कॉल

var x uint8 = 255
bits.OnesCount(x)

फिर निम्नलिखित जेनरेट किए गए फ़ंक्शन को कॉल करेगा (नाम यहां महत्वपूर्ण नहीं है):

func $OnesCount_uint8(x uint8) {
    // separate uint8 functionality...
}

@jba यह एक दिलचस्प प्रस्ताव है, लेकिन मेरे लिए यह ज्यादातर इस तथ्य पर प्रकाश डालता है कि पैरामीट्रिक फ़ंक्शन की परिभाषा आमतौर पर इसकी बाधाओं को परिभाषित करने के लिए पर्याप्त है।

यदि आप बाधाओं के रूप में "फ़ंक्शन में उपयोग किए जाने वाले ऑपरेटरों" का उपयोग करने जा रहे हैं, तो पहले में उपयोग किए गए ऑपरेटरों के सबसेट वाले दूसरे फ़ंक्शन को लिखने से आपको क्या फायदा होता है?

@bcmills उनमें से एक कल्पना है और दूसरा कार्यान्वयन है। यह स्थिर टाइपिंग के समान ही लाभ है: आप पहले त्रुटियों को पकड़ सकते हैं।

यदि कार्यान्वयन कल्पना है, एक ला सी ++ टेम्पलेट्स, तो कार्यान्वयन में कोई भी परिवर्तन संभावित रूप से आश्रितों को तोड़ देता है। यह बहुत बाद में खोजा नहीं जा सकता है, जब आश्रित पुन: संकलित होते हैं, और खोजकर्ताओं के पास त्रुटि संदेश को समझने के लिए कोई संदर्भ नहीं होता है। उसी पैकेज में विशिष्टता के साथ, आप स्थानीय रूप से टूट-फूट का पता लगा सकते हैं।

@mandolyte मुझे पूरा यकीन नहीं है कि इसे कहां जोड़ना है - शायद 'जेनेरिक दृष्टिकोण' के तहत एक पैराग्राफ जिसका नाम 'जेनेरिक विथ बाधाओं' है?
दस्तावेज़ में सीमित प्रकार के पैरामीटर के बारे में बहुत कुछ शामिल नहीं है, इसलिए यदि आपने एक पैराग्राफ जोड़ा है जहां मेरे प्रस्ताव का उल्लेख किया जाएगा, तो बाधाओं के अन्य तरीकों को भी वहां सूचीबद्ध किया जा सकता है।

@surlykke दस्तावेज़ पर सामान्य दृष्टिकोण एक बदलाव करना है जो सही लगता है और मैं इसे बाकी दस्तावेज़ के साथ स्वीकार करने, शामिल करने और व्यवस्थित करने का प्रयास करूंगा। मैंने यहां एक सेक्शन जोड़ा है। उन चीजों को जोड़ने के लिए स्वतंत्र महसूस करें जो मुझे याद आती हैं।

@egonelbre यह बहुत अच्छा है। धन्यवाद!

@jba
मुझे आपका प्रस्ताव पसंद है, लेकिन मुझे लगता है कि यह गोलंग के लिए बहुत भारी है। यह मुझे सी ++ में बहुत सारे टेम्पलेट्स की याद दिलाता है। मुझे लगता है कि मुख्य समस्या यह है कि आप इसके साथ वास्तव में जटिल कोड लिख सकते हैं।
यह तय करने के लिए कि क्या दो सामान्य इंटरफ़ेस इंस्टेंस ओवरलैप होते हैं क्योंकि ओवरलैप प्रकार के बाधित सेट धीमे संकलन समय के कारण कठिन कार्य होंगे। कोड पीढ़ी के लिए वही।

मुझे लगता है कि प्रस्तावित बाधाएं जाने के लिए अधिक हल्की हैं। मैंने जो सुना है वह यह है कि बाधाओं उर्फ ​​​​टाइपक्लास को भाषा की प्रकार प्रणाली में ऑर्थोगोनल लागू किया जा सकता है।

मुझे इस बात से दृढ़ता से सहमत होना होगा कि हमें समारोह के शरीर से निहित बाधाओं के साथ नहीं जाना चाहिए। उन्हें व्यापक रूप से सी ++ टेम्पलेट्स में से एक माना जाता है 'सबसे महत्वपूर्ण मिसफीचर्स:

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

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

• अन्य सामान्य कार्यों में सामान्य कार्यों को कॉल करना उपरोक्त स्थितियों को बदतर बना देता है, क्योंकि अब आपको उस फ़ंक्शन की बाधाओं को समझने के लिए सभी कॉलीज़ की बाधाओं को देखने की आवश्यकता है जो आप लिख रहे हैं या पढ़ रहे हैं।
• डिबगिंग बहुत मुश्किल हो सकती है, क्योंकि त्रुटि संदेशों को या तो बाधा के स्रोत को खोजने के लिए पर्याप्त जानकारी प्रदान नहीं करनी चाहिए, या उन्हें फ़ंक्शन के आंतरिक विवरण को लीक करना चाहिए। उदाहरण के लिए, यदि F को T प्रकार पर कुछ आवश्यकता है, और F के लेखक यह पता लगाने की कोशिश कर रहे हैं कि यह आवश्यकता कहां से आई है, तो वे चाहते हैं कि कंपाइलर उन्हें सचेत करें कि कौन सा कथन बाधा को जन्म देता है (विशेषकर यदि यह एक सामान्य कैली से आता है)। लेकिन F का उपयोगकर्ता उस जानकारी को नहीं चाहता है और वास्तव में, यदि इसे त्रुटि संदेशों में शामिल किया गया है, तो हम इसके उपयोगकर्ताओं से त्रुटि संदेशों में F के कार्यान्वयन विवरण लीक कर रहे हैं, जो एक भयानक उपयोगकर्ता अनुभव हैं।

@alercah

उदाहरण के लिए, क्या मुझे निम्नलिखित फ़ंक्शन को परिभाषित करने की अनुमति है?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

नहीं, u.v(V) एक सिंटैक्स त्रुटि है क्योंकि V एक प्रकार है, और चर t अप्रयुक्त है।

हालांकि, आप इस फ़ंक्शन को परिभाषित कर सकते हैं, जो कि आपका इरादा हो सकता है:

func[T, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

यहां टी, यू और वी पर वास्तविक बाधाएं क्या हैं?

• प्रकार V अप्रतिबंधित है।
• प्रकार U में एक विधि v $ होनी चाहिए जो V से असाइन करने योग्य किसी प्रकार के एकल पैरामीटर या varargs को स्वीकार करती है, क्योंकि u.v को एक तर्क के साथ लागू किया जाता है V प्रकार का।
  
  
  
  • U.v फ़ंक्शन प्रकार का एक क्षेत्र हो सकता है, लेकिन यकीनन यह एक विधि का अर्थ होना चाहिए; #23796 देखें।
  
  
• U.v द्वारा लौटाया गया प्रकार संख्यात्मक होना चाहिए, क्योंकि इसमें निरंतर 1 जोड़ा जाता है।
• U.v T असाइन करने योग्य होना चाहिए, क्योंकि u.v(…) + 1 को T प्रकार के वेरिएबल को असाइन किया गया है।
• प्रकार T संख्यात्मक होना चाहिए, क्योंकि U.v का वापसी प्रकार संख्यात्मक है और T को असाइन किया जा सकता है।

(एक तरफ: आप तर्क दे सकते हैं कि U और V में बाधा "प्रतिलिपि योग्य" होनी चाहिए क्योंकि उन प्रकारों के तर्क मूल्य द्वारा पारित किए जाते हैं, लेकिन मौजूदा, गैर-जेनेरिक प्रकार प्रणाली लागू नहीं होती है वह बाधा या तो। यह एक अलग प्रस्ताव की बात है।)

यदि हमें प्रोग्रामर को स्पष्ट रूप से बाधाओं को निर्दिष्ट करने की आवश्यकता है, तो हम जिस तरह की बाधाओं की अनुमति देते हैं, उसमें हम रूढ़िवादी हैं (हमें इसे धीरे-धीरे और जानबूझकर विस्तारित करने दें)।

हां, यह सच है: लेकिन एक बाधा को छोड़ना एक गंभीर दोष होगा चाहे वे बाधाएं निहित हों या नहीं। आईएमओ, अस्पष्टता को हल करने के लिए बाधाओं की अधिक महत्वपूर्ण भूमिका है। उदाहरण के लिए, उपरोक्त बाधाओं में, कंपाइलर को u.v को एकल-तर्क या भिन्न विधि के रूप में तत्काल करने के लिए तैयार रहना चाहिए।

सबसे दिलचस्प अस्पष्टता शाब्दिक के लिए होती है, जहां हमें संरचना प्रकारों और समग्र प्रकारों के बीच स्पष्ट करने की आवश्यकता होती है:

func[T] Foo() (t T) {
    x := 42;
    t = T{x: "some string"}  // Is x an index, or a field name?
    _ = x
}

अगर हम वैसे भी रूढ़िवादी होने की कोशिश करते हैं, तो हम इस तरह के फ़ंक्शन के लिए त्रुटि संदेश कैसे देते हैं? "त्रुटि: टी को यूवी () असाइन नहीं कर सकता क्योंकि यह एक अवैध बाधा लगाता है"?

मुझे पूरा यकीन नहीं है कि आप क्या पूछ रहे हैं, क्योंकि मुझे इस उदाहरण के लिए विरोधाभासी बाधाएं नहीं दिख रही हैं। "अवैध प्रतिबंध" से आपका क्या तात्पर्य है?

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

प्रत्येक प्रासंगिक बाधा को टाइप सिस्टम द्वारा व्यक्त नहीं किया जा सकता है (यह भी देखें https://github.com/golang/go/issues/22876#issuecomment-347035323)। कुछ बाधाओं को रन-टाइम पैनिक द्वारा लागू किया जाता है; कुछ रेस डिटेक्टर द्वारा लागू किए जाते हैं; सबसे खतरनाक बाधाओं को केवल प्रलेखित किया जाता है और उनका पता नहीं लगाया जाता है।

वे सभी कुछ हद तक "आंतरिक विवरण लीक" करते हैं। (https://xkcd.com/1172/ भी देखें।)

उदाहरण के लिए, यदि एफ का लेखक यह पता लगाने की कोशिश कर रहा है कि यह आवश्यकता कहां से आई है, तो वे चाहते हैं कि संकलक उन्हें सचेत करे कि कौन सा कथन बाधा को जन्म देता है (विशेषकर यदि यह एक सामान्य कैली से आता है)। लेकिन F का एक उपयोगकर्ता वह जानकारी नहीं चाहता है[।]

शायद? इस प्रकार एपीआई लेखक टाइप-अनुमानित भाषाओं जैसे हास्केल और एमएल में टाइप एनोटेशन का उपयोग करते हैं, लेकिन यह सामान्य रूप से गहरे पैरामीट्रिक ("उच्च-क्रम") प्रकारों के खरगोश-छेद की ओर भी जाता है।

उदाहरण के लिए, मान लें कि आपके पास यह फ़ंक्शन है:

func [F, Arg, Result] InvokeAsync(f F, x Arg) (<-chan Result) {
    c := make(chan result, 1)
    go func() { c <- f(x) }()
    return c
}

आप Arg प्रकार पर स्पष्ट बाधाओं को कैसे व्यक्त करते हैं? वे F की विशिष्ट तात्कालिकता पर निर्भर करते हैं। ऐसा लगता है कि इस तरह की निर्भरता बाधाओं के हालिया प्रस्तावों में से कई से गायब है।

नहीं, यूवी (वी) एक वाक्यविन्यास त्रुटि है क्योंकि वी एक प्रकार है, और चर टी अप्रयुक्त है।

हालांकि, आप इस फ़ंक्शन को परिभाषित कर सकते हैं, जो कि आपका इरादा हो सकता है:

हाँ, यही इरादा था, क्षमा करें।

प्रकार T संख्यात्मक होना चाहिए, क्योंकि U.v का वापसी प्रकार संख्यात्मक है और T को असाइन किया जा सकता है।

क्या हमें वास्तव में इसे एक बाधा मानना ​​चाहिए? यह अन्य बाधाओं से घटाया जा सकता है, लेकिन क्या इसे एक अलग बाधा कहने के लिए कमोबेश उपयोगी है? निहित बाधाएं इस सवाल को इस तरह से पूछती हैं कि स्पष्ट बाधाएं नहीं हैं।

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

मेरा मतलब था "बाधाओं की हम अनुमति देते हैं" जैसा कि भाषा में है। स्पष्ट बाधाओं के साथ, हमारे लिए यह तय करना बहुत आसान है कि हम किस तरह की बाधाओं को उपयोगकर्ताओं को लिखने की अनुमति देने के लिए तैयार हैं, बजाय इसके कि "जो कुछ भी चीजों को संकलित करता है" बाधा है। उदाहरण के लिए, ऊपर मेरे उदाहरण Foo में वास्तव में T , U , या V से अलग एक अंतर्निहित अतिरिक्त प्रकार शामिल है, क्योंकि हमें वापसी प्रकार पर विचार करना चाहिए u.v । इस प्रकार को f की घोषणा में किसी भी तरह से स्पष्ट रूप से संदर्भित नहीं किया गया है; इसके जो गुण होने चाहिए वह पूरी तरह से निहित हैं। इसी तरह, क्या हम उच्च-रैंक वाले ( forall ) प्रकारों की अनुमति देने के इच्छुक हैं? मैं अपने सिर के ऊपर से एक उदाहरण के साथ नहीं आ सकता, लेकिन मैं खुद को यह भी नहीं समझा सकता कि आप एक उच्च-रैंक प्रकार की बाध्यता नहीं लिख सकते।

एक अन्य उदाहरण यह है कि क्या हमें किसी फ़ंक्शन को अतिभारित सिंटैक्स का लाभ उठाने की अनुमति देनी चाहिए। यदि एक अंतर्निहित-विवश फ़ंक्शन for i := range t जेनेरिक प्रकार T $ के कुछ t के लिए करता है, तो सिंटैक्स काम करता है यदि T कोई सरणी, टुकड़ा, चैनल है, या नक्शा। लेकिन शब्दार्थ काफी भिन्न हैं, खासकर यदि T एक चैनल प्रकार है। उदाहरण के लिए, यदि t == nil (जो तब तक हो सकता है जब तक T एक सरणी है), तो पुनरावृत्ति या तो कुछ नहीं करती है, क्योंकि शून्य स्लाइस या मानचित्र में कोई तत्व नहीं हैं, या हमेशा के लिए ब्लॉक हो जाते हैं चूंकि nil चैनलों पर यही प्राप्त होता है। यह एक बड़ा फुटगन होने का इंतजार कर रहा है। इसी तरह कर रहा है m[i] = ... ; अगर मैं एक नक्शा बनने के लिए m का इरादा रखता हूं, तो मुझे इसके खिलाफ वास्तव में एक टुकड़ा होने की रक्षा करने की आवश्यकता होगी क्योंकि कोड अन्यथा आउट-ऑफ-रेंज असाइनमेंट पर घबरा सकता है।

वास्तव में, मुझे लगता है कि यह खुद को निहित बाधाओं के खिलाफ एक और तर्क के लिए उधार देता है: एपीआई लेखक केवल बाधाओं को जोड़ने के लिए कृत्रिम बयान लिख सकते हैं। उदाहरण के लिए for _, _ := range t { break } नक्शे, स्लाइस और सरणियों की अनुमति देते हुए एक चैनल को रोकता है; x = append(x) स्लाइस प्रकार रखने के लिए x को बाध्य करता है। var _ = make(T, 0) स्लाइस, मैप और चैनल की अनुमति देता है लेकिन सरणियों को नहीं। कैसे परोक्ष रूप से बाधाओं को जोड़ने के लिए एक नुस्खा पुस्तक होगी ताकि कोई आपके फ़ंक्शन को उस प्रकार से कॉल न कर सके जिसके लिए आपने सही कोड नहीं लिखा है। मैं कोड लिखने के तरीके के बारे में सोच भी नहीं सकता जो केवल मानचित्र प्रकारों के लिए संकलित करता है जब तक कि मैं कुंजी प्रकार को भी नहीं जानता। और मुझे नहीं लगता कि यह काल्पनिक है; अधिकांश आवेदकों के लिए मानचित्र और स्लाइस काफी भिन्न व्यवहार करते हैं

मुझे पूरा यकीन नहीं है कि आप क्या पूछ रहे हैं, क्योंकि मुझे इस उदाहरण के लिए विरोधाभासी बाधाएं नहीं दिख रही हैं। "अवैध प्रतिबंध" से आपका क्या तात्पर्य है?

मेरा मतलब एक बाधा है जिसकी भाषा द्वारा अनुमति नहीं है, जैसे कि यदि भाषा उच्च-रैंक वाली बाधाओं को अस्वीकार करने का निर्णय लेती है।

प्रत्येक प्रासंगिक बाधा को टाइप सिस्टम द्वारा व्यक्त नहीं किया जा सकता है (#22876 (टिप्पणी) भी देखें)। कुछ बाधाओं को रन-टाइम पैनिक द्वारा लागू किया जाता है; कुछ रेस डिटेक्टर द्वारा लागू किए जाते हैं; सबसे खतरनाक बाधाओं को केवल प्रलेखित किया जाता है और उनका पता नहीं लगाया जाता है।

वे सभी कुछ हद तक "आंतरिक विवरण लीक" करते हैं। (https://xkcd.com/1172/ भी देखें।)

मैं वास्तव में नहीं देखता कि इसमें #22876 कैसे आता है; यह एक अलग तरह की बाधा को व्यक्त करने के लिए टाइप सिस्टम का उपयोग करने की कोशिश कर रहा है। यह हमेशा सत्य होगा कि हम मूल्यों पर या कार्यक्रमों पर कुछ बाधाओं को व्यक्त नहीं कर सकते, यहां तक ​​​​कि मनमानी जटिलता की एक प्रकार की प्रणाली के साथ भी। लेकिन हम यहां केवल प्रकारों पर बाधाओं के बारे में बात कर रहे हैं। कंपाइलर को इस सवाल का जवाब देने में सक्षम होना चाहिए "क्या मैं इस जेनेरिक को टाइप T के साथ इंस्टेंट कर सकता हूं?" जिसका अर्थ है कि इसे बाधाओं को समझना चाहिए, चाहे वे निहित हों या स्पष्ट। (ध्यान दें कि कुछ भाषाएं, जैसे सी ++ और रस्ट, इस प्रश्न को सामान्य रूप से तय नहीं कर सकती हैं क्योंकि यह मनमानी गणना पर निर्भर हो सकती है और इस प्रकार हॉल्टिंग समस्या के लिए समर्पित है, लेकिन वे अभी भी उन बाधाओं को व्यक्त करते हैं जिन्हें संतुष्ट करने की आवश्यकता है।)

मेरा मतलब यह है कि "निम्न उदाहरण क्या त्रुटि संदेश देना चाहिए?"

func [U] DirectlyConstrained(U t) {
    t.DoSomething();
}
func [T] IndirectlyConstrained(T t) {
    DirectlyConstrainted(t);
}
func Illegal() {
    IndirectlyConstrained(4);
}

हम कह सकते हैं Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() । यह त्रुटि संदेश IndirectlyConstrained के उपयोगकर्ता के लिए सहायक है, क्योंकि यह स्पष्ट रूप से उन सीमाओं को निर्धारित करता है जो वे गायब हैं। लेकिन यह डिबग करने की कोशिश कर रहे किसी व्यक्ति को कोई जानकारी नहीं देता है कि IndirectlyConstrained में वह बाधा क्यों है, जो एक बड़ी उपयोगिता समस्या है यदि यह एक बड़ा कार्य है। हम Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N जोड़ सकते थे, लेकिन अब हम IndirectlyConstrained के कार्यान्वयन का विवरण लीक कर रहे हैं। इसके अलावा, हमने यह नहीं बताया है कि IndirectlyConstrained में बाधा क्यों है, तो क्या हम एक और Note: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line M जोड़ते हैं? क्या होगा यदि कॉल स्टैक के नीचे कुछ कॉली चार स्तरों से निहित बाधा आती है?

इसके अलावा, हम इस त्रुटि संदेशों को उन प्रकारों के लिए कैसे प्रारूपित करते हैं जो स्पष्ट रूप से पैरामीटर के रूप में सूचीबद्ध नहीं हैं? उदाहरण के लिए यदि उपरोक्त उदाहरण में, IndirectlyConstrained कॉल DirectlyConstrained(t.U()) । हम इस प्रकार का भी उल्लेख कैसे करते हैं? इस मामले में हम कह सकते हैं the type of t.U() , लेकिन यह जरूरी नहीं कि मान एक व्यंजक का परिणाम हो; इसे कई कथनों पर बनाया जा सकता है। फिर हमें या तो त्रुटि संदेश में डालने के लिए सही प्रकार के साथ एक अभिव्यक्ति को संश्लेषित करने की आवश्यकता होगी, एक जो कोड में कभी प्रकट नहीं होता है, या हमें इसे संदर्भित करने के लिए कोई अन्य तरीका खोजने की आवश्यकता होगी जो कि कम स्पष्ट होगा गरीब कॉलर जिसने बाधा का उल्लंघन किया।

आप Arg प्रकार पर स्पष्ट बाधाओं को कैसे व्यक्त करते हैं? वे एफ की विशिष्ट तात्कालिकता पर निर्भर करते हैं। उस तरह की निर्भरता बाधाओं के हालिया प्रस्तावों में से कई से गायब प्रतीत होती है।

F ड्रॉप करें और f का प्रकार func (Arg) Result । हां, यह विविध कार्यों को अनदेखा करता है, लेकिन बाकी गो भी करता है। संगत हस्ताक्षरों के लिए varargs funcs असाइन करने योग्य बनाने का प्रस्ताव अलग से किया जा सकता है।

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

कृपया अपने अगले प्रोजेक्ट में मेरे जेनरिक कार्यान्वयन का मूल्यांकन करें
http://go-li.github.io/

हम कह सकते हैं Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() । यह त्रुटि संदेश [...] डीबग करने का प्रयास करने वाले किसी व्यक्ति को कोई जानकारी प्रदान नहीं करता है कि IndirectlyConstrained में वह बाधा क्यों है, जो कि एक बड़ी उपयोगिता समस्या है यदि यह एक बड़ा कार्य है।

मैं एक बड़ी धारणा को इंगित करना चाहता हूं जो आप यहां बना रहे हैं: कि go build से त्रुटि संदेश _only_ उपकरण है जो प्रोग्रामर के पास समस्या का निदान करने के लिए उपलब्ध है।

एक सादृश्य का उपयोग करने के लिए: यदि आप रन-टाइम पर error का सामना करते हैं, तो आपके पास डिबगिंग के लिए कई विकल्प हैं। त्रुटि में केवल एक साधारण संदेश होता है, जो त्रुटि का वर्णन करने के लिए पर्याप्त हो भी सकता है और नहीं भी। लेकिन यह एकमात्र जानकारी नहीं है जो आपके पास उपलब्ध है: उदाहरण के लिए, आपके पास प्रोग्राम द्वारा उत्सर्जित लॉग स्टेटमेंट भी हैं, और यदि यह वास्तव में एक गड़बड़ बग है तो आप इसे एक इंटरैक्टिव डीबगर में लोड कर सकते हैं।

अर्थात्, रन-टाइम डिबगिंग एक इंटरैक्टिव प्रक्रिया है। तो हमें संकलन-समय त्रुटियों के लिए गैर-संवादात्मक डिबगिंग क्यों माननी चाहिए⸮ एक विकल्प के रूप में, हम प्रकार की बाधाओं के बारे में guru टूल सिखा सकते हैं। फिर, कंपाइलर से आउटपुट कुछ ऐसा होगा:

somefile.go:123: Argument `4` to DirectlyConstrained has type `int`,
    but DirectlyConstrained requires a type `T` with method `DoSomething()`.
    (For more detail, run `guru contraints path/to/somefile.go:#1033`.)

यह जेनेरिक पैकेज के उपयोगकर्ता को तत्काल कॉल साइट को डीबग करने के लिए आवश्यक जानकारी देता है, लेकिन _also_ आगे की जांच के लिए पैकेज मेंटेनर (और, महत्वपूर्ण रूप से, उनके संपादन वातावरण!) के लिए एक ब्रेडक्रंब देता है।

हम Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N जोड़ सकते थे, लेकिन अब हम IndirectlyConstrained के कार्यान्वयन का विवरण लीक कर रहे हैं।

हां, वैसे भी लीक होने वाली जानकारी के बारे में मेरा यही मतलब है। कार्यान्वयन के अंदर झांकने के लिए आप पहले से ही guru describe का उपयोग कर सकते हैं। आप डिबगर का उपयोग करके एक चल रहे प्रोग्राम के अंदर झांक सकते हैं, और न केवल स्टैक को देख सकते हैं, बल्कि मनमाने ढंग से निम्न-स्तरीय कार्यों में भी कदम रख सकते हैं।

मैं इस बात से पूरी तरह सहमत हूं कि हमें डिफ़ॉल्ट रूप से संभावित-अप्रासंगिक जानकारी छिपानी चाहिए, लेकिन इसका मतलब यह नहीं है कि हमें इसे पूर्ण रूप से छिपाना चाहिए।

यदि एक अंतर्निहित-विवश फ़ंक्शन i := range t के लिए सामान्य प्रकार के $ t के लिए सामान्य प्रकार T के लिए करता है, तो सिंटैक्स काम करता है यदि T कोई सरणी, टुकड़ा, चैनल है , या नक्शा। लेकिन शब्दार्थ काफी भिन्न हैं, खासकर यदि T एक चैनल प्रकार है।

मुझे लगता है कि यह प्रकार की बाधाओं के लिए अधिक सम्मोहक तर्क है, लेकिन इसके लिए स्पष्ट बाधाओं की आवश्यकता नहीं है कि वे वर्बोज़ के पास कहीं भी हों जैसा कि कुछ लोग प्रस्तावित कर रहे हैं। कॉल साइटों को स्पष्ट करने के लिए, टाइप पैरामीटर को reflect.Kind के करीब कुछ सीमित करने के लिए पर्याप्त लगता है। हमें उन कार्यों का वर्णन करने की आवश्यकता नहीं है जो कोड से पहले से ही स्पष्ट हैं; इसके बजाय, हमें केवल " T एक टुकड़ा प्रकार है" जैसी बातें कहने की आवश्यकता है। इससे बाधाओं का एक बहुत आसान सेट होता है:

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

यह एक बहुत ही संकुचित बाधा भाषा की ओर जाता है, शायद कुछ ऐसा:

TypeConstraint = "sliceable" | "map" | "chan" | "struct" | "integer" | "float" | "type"

जैसे उदाहरणों के साथ:

func[T:integer, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

func [S:sliceable, T] append(s S, x ...T) S {
    dst := s
    if cap(s) - len(s) < len(x) {
        dst = make(S, len(s), nextSizeClass(cap(s)))
        copy(dst, s)
    }
    copy(dst[len(s):cap(s)], x)
    return dst[:len(s)+len(x)]
}

मुझे लगता है कि हमने टाइप अलियास को पेश करके कस्टम जेनेरिक की ओर एक बड़ा कदम बढ़ाया है।
प्रकार उपनाम सुपर प्रकार (प्रकार के प्रकार) को संभव बनाता है।
हम उपयोग में मूल्यों जैसे प्रकारों का इलाज कर सकते हैं।

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

प्रत्येक प्रकार का प्रकार, संरचना और इंटरफ़ेस और फ़ंक्शन प्रकारों को छोड़कर, एक पूर्व-घोषित शैली से मेल खाता है।

• बूल
• डोरी
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint, Uintptr
• फ्लोट 32, फ्लोट 64
• कॉम्प्लेक्स64, कॉम्प्लेक्स128
• ऐरे, स्लाइस, मैप, चैनल, पॉइंटर, असुरक्षित पॉइंटर

कुछ अन्य पूर्व-घोषित शैलियाँ हैं, जैसे कि कोमाप्रेबल, न्यूमेरिक, इंटरगर, फ्लोट, कॉम्प्लेक्स, कंटेनर, आदि। हम Type या * का उपयोग कर सकते हैं जो सभी प्रकार की शैली को दर्शाता है।

सभी अंतर्निहित शैलियों के नाम सभी एक बड़े अक्षर से शुरू होते हैं।

प्रत्येक संरचना और इंटरफ़ेस और फ़ंक्शन प्रकार एक शैली से मेल खाते हैं।

हम कस्टम शैलियों की भी घोषणा कर सकते हैं:

genre Addable = Numeric | String
genre Orderable = Interger | Float | String
genre Validator = func(int) bool // each parameter and result type must be a specified type.
genre HaveFieldsAndMethods = {
    width  int // we must use a specific type to define the fields.
    height int // we can't use a genre to define the fields.
    Load(v []byte) error // each parameter and result type must be a specified type.
    DoSomthing()
}
genre GenreFromStruct = aStructType // declare a genre from a struct type
genre GenreFromInterface = anInterfaceType // declare a genre from an interface type
genre GenreFromStructInterface = aStructType + anInterfaceType
genre ComparableStruct = HaveFieldsAndMethods & Comprable
genre UncomparableStruct = HaveFieldsAndMethods &^ Comprable

निम्नलिखित व्याख्या को सुसंगत बनाने के लिए, एक शैली संशोधक की आवश्यकता है।
शैली संशोधक को Const द्वारा दर्शाया गया है। उदाहरण के लिए:

• Const Integer एक शैली है ( Integer से अलग) और इसका उदाहरण एक स्थिर मान होना चाहिए जो प्रकार एक पूर्णांक होना चाहिए। हालांकि, निरंतर मूल्य को एक विशेष प्रकार के रूप में देखा जा सकता है।
• Const func(int) bool एक शैली है ( func(int) bool से अलग) और इसका उदाहरण एक डेलकेयर फ़ंक्शन मान होना चाहिए। हालाँकि, फ़ंक्शन घोषणा को एक विशेष प्रकार के रूप में देखा जा सकता है।

(संशोधक समाधान कुछ मुश्किल है, शायद अन्य बेहतर डिज़ाइन समाधान हैं।)

ठीक है, चलो जारी रखें।
हमें एक और अवधारणा की जरूरत है। इसके लिए एक अच्छा नाम खोजना आसान नहीं है,
चलो बस इसे crate कहते हैं।
आम तौर पर, बक्से और शैलियों के बीच का संबंध कार्यों और प्रकारों के बीच के संबंध की तरह होता है।
एक टोकरा पैरामीटर और रिटर्न प्रकार के रूप में प्रकार ले सकता है।

एक टोकरा घोषणा (मान लें कि निम्नलिखित कोड lib पैकेज में घोषित किया गया है):

crate Example [T Float, S {width, height T}, N Const Integer] [*, *, *] {
    type MyArray [N]T

    func Add(a, b T) T {
        return a+b
    }

    type M struct {
        x T
        y S
    }

    func (m *M) Area() T {
        m.DoSomthing()
        return m.y.width * m.y.height
    }

    func (m *M) Perimeter() T {
        return 2 * Add(m.y.width, m.y.height)
    }

    export M, Add, MyArray
}

उपरोक्त टोकरे का उपयोग करना।

import "lib"

// We can use AddFunc as a normal delcared function.
// Its genre is "Const func (a, b T) T"
type Rect, AddFunc, Array = lib.Example[float32, struct{x, y float32}, 100]

func demo() {
    var r Rect
    a, p = r.Area(), r.Perimeter()
    _ = AddFunc(a, p)
}

मेरे विचार ऊपर दिखाए गए अन्य लोगों के कई विचारों को अवशोषित करते हैं।
वे अब बहुत परिपक्व नहीं हैं।
मैं उन्हें यहाँ सिर्फ इसलिए पोस्ट करता हूँ क्योंकि मुझे लगता है कि वे कुछ दिलचस्प हैं,
और मैं इसमें और सुधार नहीं करना चाहता।
विचारों में छेद को ठीक करके मस्तिष्क की कई कोशिकाओं को मार दिया गया।
मुझे आशा है कि ये विचार अन्य गोफरों के लिए कुछ प्रेरणा ला सकते हैं।

जिसे आप "शैली" कहते हैं, उसे वास्तव में "दयालु" कहा जाता है, और यह प्रसिद्ध है
कार्यात्मक प्रोग्रामिंग समुदाय। जिसे आप टोकरा कहते हैं वह प्रतिबंधित है
एमएल functor की तरह।

बुधवार, 4 अप्रैल, 2018 को दोपहर 12:41 बजे dotaheor [email protected] ने लिखा:

मुझे लगता है कि हमने शुरू करके कस्टम जेनेरिक की ओर एक बड़ा कदम बढ़ाया है
उपनाम टाइप करें।
प्रकार उपनाम सुपर प्रकार (प्रकार के प्रकार) को संभव बनाता है।
हम उपयोग में मूल्यों जैसे प्रकारों का इलाज कर सकते हैं।

व्याख्याओं को सरल बनाने के लिए, हम एक नया कोड तत्व, शैली जोड़ सकते हैं।
शैलियों और प्रकारों के बीच का संबंध प्रकारों के बीच के संबंध की तरह है
और मूल्य।
दूसरे शब्दों में, एक शैली का अर्थ है एक प्रकार का प्रकार।

संरचना और इंटरफ़ेस और फ़ंक्शन प्रकारों को छोड़कर प्रत्येक प्रकार का,
एक पूर्व-घोषित शैली से मेल खाती है।

• बूल
• डोरी
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint,
  Uintptr
  फ्लोट32, फ्लोट64
• कॉम्प्लेक्स64, कॉम्प्लेक्स128
• ऐरे, स्लाइस, मैप, चैनल, पॉइंटर, असुरक्षित पॉइंटर

कुछ अन्य पूर्व-घोषित शैलियाँ हैं, जैसे कि तुलनात्मक, संख्यात्मक,
इंटरगर, फ्लोट, कॉम्प्लेक्स, कंटेनर, आदि। हम टाइप या * का उपयोग कर सकते हैं
सभी प्रकार की शैली।

सभी अंतर्निहित शैलियों के नाम सभी एक बड़े अक्षर से शुरू होते हैं।

प्रत्येक संरचना और इंटरफ़ेस और फ़ंक्शन प्रकार एक शैली से मेल खाते हैं।

हम कस्टम शैलियों की भी घोषणा कर सकते हैं:

शैली जोड़ने योग्य = संख्यात्मक | डोरी
जॉनर ऑर्डरेबल = इंटरगर | फ्लोट | डोरी
शैली सत्यापनकर्ता = func (int) बूल // प्रत्येक पैरामीटर और परिणाम प्रकार एक निर्दिष्ट प्रकार होना चाहिए।
शैली HaveFieldsAndMethods = {
चौड़ाई इंट // हमें फ़ील्ड को परिभाषित करने के लिए एक विशिष्ट प्रकार का उपयोग करना चाहिए।
ऊंचाई इंट // हम क्षेत्रों को परिभाषित करने के लिए एक शैली का उपयोग नहीं कर सकते।
लोड (v [] बाइट) त्रुटि // प्रत्येक पैरामीटर और परिणाम प्रकार एक निर्दिष्ट प्रकार होना चाहिए।
कुछ करना ()
}
शैली GenreFromStruct = aStructType // एक स्ट्रक्चर प्रकार से एक शैली घोषित करें
शैली GenreFromInterface = anInterfaceType // एक इंटरफ़ेस प्रकार से एक शैली घोषित करें
शैली GenreFromStructInterface = aStructType | एक इंटरफ़ेस प्रकार

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

• कॉन्स्ट इंटीजर एक शैली है और इसका उदाहरण एक स्थिर मान होना चाहिए
  कौन सा प्रकार एक पूर्णांक होना चाहिए।
  हालांकि, निरंतर मूल्य को एक विशेष प्रकार के रूप में देखा जा सकता है।
• Const func(int) bool एक शैली है और इसका उदाहरण एक डेलकेयर होना चाहिए
  समारोह मूल्य।
  हालाँकि, फ़ंक्शन घोषणा को एक विशेष प्रकार के रूप में देखा जा सकता है।

(संशोधक समाधान कुछ मुश्किल है, शायद अन्य बेहतर डिज़ाइन हैं
समाधान।)

ठीक है, चलो जारी रखें।
हमें एक और अवधारणा की जरूरत है। इसके लिए एक अच्छा नाम खोजना आसान नहीं है,
चलो बस इसे टोकरा कहते हैं।
आम तौर पर, बक्से और शैलियों के बीच का संबंध संबंध की तरह होता है
कार्यों और प्रकारों के बीच।
एक टोकरा पैरामीटर और रिटर्न प्रकार के रूप में प्रकार ले सकता है।

एक टोकरा घोषणा (मान लें कि निम्नलिखित कोड lib . में घोषित किया गया है)
पैकेज):

क्रेट उदाहरण [टी फ्लोट, एस {चौड़ाई, ऊंचाई टी}, एन कॉन्स्ट इंटीजर] [*, *, *] {
MyArray टाइप करें [N]T

func जोड़ें (ए, बी टी) टी {
वापसी ए+बी
}

// एक टोकरा-स्कोप शैली। केवल टोकरा में इस्तेमाल किया जा सकता है।

// M एक प्रकार की शैली है G
एम संरचना टाइप करें {
एक्स टी
वाई सो
}

func (एम * एम) क्षेत्र () टी {
m.DoSomthing ()
mywidth * myheight . लौटाएं
}

func (एम * एम) परिधि () टी {
वापसी 2 * जोड़ें (mywidth, myheight)
}

निर्यात एम, जोड़ें, MyArray
}

उपरोक्त टोकरे का उपयोग करना।

आयात "लिब"

// हम AddFunc को एक सामान्य डेलकेयर फ़ंक्शन के रूप में उपयोग कर सकते हैं।
Rect, AddFunc, Array = lib.Example टाइप करें (float32, struct{x, y float32})

func डेमो () {
वर आर रेक्ट
a, p = r.Area (), r.Perimeter ()
_ = AddFunc (ए, पी)
}

मेरे विचार ऊपर दिखाए गए अन्य लोगों के कई विचारों को अवशोषित करते हैं।
वे अब बहुत परिपक्व नहीं हैं।
मैं उन्हें यहाँ सिर्फ इसलिए पोस्ट करता हूँ क्योंकि मुझे लगता है कि वे कुछ दिलचस्प हैं,
और मैं इसमें और सुधार नहीं करना चाहता।
विचारों में छेद को ठीक करके मस्तिष्क की कई कोशिकाओं को मार दिया गया।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-378665695 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWB78BrjN0BxRfroH-jRNy4mCXgSwCks5tlPfMgaJpZM4IG-xv
.

मुझे लगता है कि काइंड और जॉनर में कुछ अंतर हैं।

वैसे, यदि कोई टोकरा केवल एक प्रकार का रिटर्न देता है, तो हम उसकी कॉल को सीधे एक प्रकार के रूप में उपयोग कर सकते हैं।

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

इसका इस्तेमाल करें:

import "lib"

var l lib.List[int]

कुछ "शैली कटौती" नियम होंगे, जैसे वर्तमान प्रणाली में "प्रकार कटौती"।

@dotaheor , @DemiMarie सही है। आपकी "शैली" अवधारणा बिल्कुल प्रकार सिद्धांत से "दयालु" की तरह लगती है। (आपके प्रस्ताव के लिए एक उप-प्रजाति नियम की आवश्यकता होती है, लेकिन यह असामान्य नहीं है।)

आपके प्रस्ताव में genre कीवर्ड नए प्रकार को मौजूदा प्रकार के सुपर-प्रकार के रूप में परिभाषित करता है। crate कीवर्ड "क्रेट सिग्नेचर" वाली वस्तुओं को परिभाषित करता है, जो एक प्रकार का है जो Type का उप-प्रकार नहीं है।

औपचारिक प्रणाली के रूप में, आपका प्रस्ताव कुछ ऐसा प्रतीत होता है:

टोकरा ::= χ | मैं
टाइप करें ::= τ | χ | int | bool | | func(τ) | func(τ) τ | []τ | χ[τ₁, …]

क्रेटसिग ::= [κ₁, …] ⇒ [κₙ, …]
तरह ::= κ | exactly τ | kindOf κ | Map | Chan | | Const κ | Type | क्रेटसिग

कुछ प्रकार-सिद्धांत संकेतन का दुरुपयोग करने के लिए:

• "⊢" को "enttails" के रूप में पढ़ें।
• “ k1 ⊑ k2 ” पढ़ें क्योंकि “ k1 k2 एक उप-प्रकार है”।
• ":" को "तरह का है" के रूप में पढ़ें।

तब नियम कुछ इस तरह दिखते हैं:

⊢ τ : exactly τ
exactly τ ⊑ kindOf exactly τ
kindOf exactly τ ⊑ Type

τ : κ₁ ∧ κ₁ ⊑ κ₂ ⊢ τ : κ₂

τ₁ : Type ∧ τ₂ : Type ⊢ kindOf exactly map[τ₁]τ₂ ⊑ Map
Map ⊑ Type

κ₁ ⊑ κ₂ ⊢ Const κ₁ ⊑ Const κ₂

[…]
(और इसी तरह, सभी अंतर्निर्मित प्रकारों के लिए)

प्रकार की परिभाषाएं प्रकार प्रदान करती हैं, और अंतर्निहित प्रकार अंतर्निहित प्रकारों के प्रकार के अनुरूप होते हैं:

type τ₁ τ₂ ∧ τ₂ : κ ⊢ τ₁ : kindOf κ

kindOf kindOf κ ⊑ kindOf κ
kindOf Map ⊑ Map
[…]

genre नए उपप्रकार संबंधों को परिभाषित करता है:
genre κ = κ₁ | κ₂ ⊢ κ₁ ⊑ κ
genre κ = κ₁ | κ₂ ⊢ κ₂ ⊑ κ

(आप Numeric और इसी तरह | के संदर्भ में परिभाषित कर सकते हैं।)

genre κ = κ₁ & κ₂ ( κ₃ ⊑ κ₁ ) ∧ ( κ₃ ⊑ κ₂ ) ⊢ κ₃ ⊑ κ

टोकरा विस्तार नियम समान है:
type τₙ, … = χ[τ₁, …] ( χ : [κ₁, …] ⇒ [κₙ, …] ) ∧ ( τ₁ : κ₁ ) τₙ : κₙ

यह सब सिर्फ प्रकारों के बारे में बात कर रहा है, बिल्कुल। यदि आप इसे टाइप सिस्टम में बदलना चाहते हैं तो आपको टाइप नियमों की भी आवश्यकता है। मैं

तो आप जो वर्णन कर रहे हैं वह पैरामीट्रिकिटी का एक बहुत अच्छी तरह से समझा जाने वाला रूप है। यह अच्छा है, इसमें यह अच्छी तरह से समझा जाता है, लेकिन निराशाजनक है कि यह गो द्वारा पेश की जाने वाली अनूठी समस्याओं को हल करने में मदद नहीं करता है।

गो द्वारा पेश की जाने वाली वास्तव में दिलचस्प और गंभीर समस्याएं मुख्य रूप से गतिशील प्रकार के निरीक्षण के आसपास हैं। टाइप पैरामीटर को टाइप-एसेर्शन और रिफ्लेक्शन के साथ कैसे इंटरैक्ट करना चाहिए?

(उदाहरण के लिए, क्या पैरामीट्रिक प्रकार के तरीकों के साथ इंटरफेस को परिभाषित करना संभव होना चाहिए? यदि हां, तो क्या होता है यदि आप रन-टाइम पर एक उपन्यास पैरामीटर के साथ उस इंटरफ़ेस का मान टाइप करते हैं?)

संबंधित नोट पर, क्या इस बारे में चर्चा हुई है कि बिल्टिन और उपयोगकर्ता-परिभाषित प्रकारों पर कोड सामान्य कैसे बनाया जाए? जैसे कोड बनाना जो बड़े और आदिम पूर्णांकों को संभाल सकता है?

संबंधित नोट पर, क्या इस बारे में चर्चा हुई है कि बिल्टिन और उपयोगकर्ता-परिभाषित प्रकारों पर कोड सामान्य कैसे बनाया जाए? जैसे कोड बनाना जो बड़े और आदिम पूर्णांकों को संभाल सकता है?

टाइप-क्लास-आधारित तंत्र, जैसे कि जीनस और फ़मिलिया, इसे कुशलता से कर सकते हैं। विवरण के लिए हमारा पीएलडीआई 2015 पेपर देखें।

@DemiMarie
मुझे लगता है कि "शैली" == "विशेषता सेट"।

[संपादित करें]
शायद traits एक बेहतर कीवर्ड है।
हम देख सकते हैं कि प्रत्येक प्रकार भी एक विशेषता सेट है।

अधिकांश लक्षण केवल एक ही प्रकार के लिए परिभाषित किए गए हैं।
लेकिन एक अधिक जटिल विशेषता दो प्रकारों के बीच संबंध को परिभाषित कर सकती है।

[2 संपादित करें]
मान लें कि दो विशेषता सेट ए और बी हैं, हम निम्नलिखित ऑपरेशन कर सकते हैं:

A + B: union set
A - B: difference set
A & B: intersection set

तर्क प्रकार का विशेषता सेट संबंधित पैरामीटर शैली (एक विशेषता सेट) का एक सुपर सेट होना चाहिए।
परिणाम प्रकार का विशेषता सेट संबंधित परिणाम शैली (एक विशेषता सेट) का एक उप सेट होना चाहिए।

(IMHO)

फिर भी मुझे लगता है कि गो में जेनरिक जोड़ने के लिए टाइप एलियास को रीबाइंड करना एक रास्ता है। इसके लिए भाषा में बड़े बदलाव की जरूरत नहीं है। इस तरह से सामान्यीकृत पैकेज, अभी भी Go 1.x में उपयोग किए जा सकते हैं। और बाधाओं को जोड़ने की कोई आवश्यकता नहीं है क्योंकि इसे अन्य प्रकार के लिए डिफ़ॉल्ट प्रकार सेट करके ऐसा करना संभव है, जो पहले से ही उन बाधाओं को पूरा करता है। और रीबाइंडिंग टाइप एलियास का सबसे महत्वपूर्ण पहलू यह है कि, बिल्ट-इन कंपोजिट टाइप्स (स्लाइस, मैप्स और चैनल) को बदलने और सामान्यीकृत करने की आवश्यकता नहीं है।

@dc0d

उपनाम कैसे टाइप करना चाहिए जेनरिक को प्रतिस्थापित करना चाहिए?

@ सिघोया रीबाइंडिंग टाइप एलियास जेनरिक को बदल सकता है (न कि केवल उपनाम टाइप करें)। आइए मान लें कि एक पैकेज कुछ पैकेज स्तर प्रकार उपनाम पेश करता है जैसे:

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

यदि टाइप एलियास रिबाइंडिंग (और कंपाइलर सुविधाएं) प्रदान की जाती हैं, तो खाली इंटरफेस के बजाय, विभिन्न ठोस प्रकारों के लिए लिंक्ड सूचियां बनाने के लिए इस पैकेज का उपयोग करना संभव है:

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

यदि हम इस तरह उपनाम का उपयोग करते हैं, तो निम्न तरीका क्लीनर है।

// pkg.go
package pkg

type ListNode struct {
    prev, next *ListNode
    element    ?Element
}

func Add(x, y ?T) ?T {
    return x+y
}



// main.go
package main

import "pkg"

type intList = pkg.ListNode[Element=int]
func stringAdd = pkg.Add[T=string]

func main() {
}

@ dc0d और इसे वास्तव में कैसे लागू किया जाएगा? कोड अच्छा है लेकिन यह इस बारे में कुछ नहीं बताता कि यह वास्तव में अंदर कैसे काम करता है। और, जेनेरिक प्रस्तावों के इतिहास को देखते हुए, गो के लिए यह बहुत महत्वपूर्ण है, न कि केवल यह कैसा दिखता है और कैसा लगता है।

@dotaheor गो 1.x के साथ असंगत है।

@creker मैंने एक टूल लागू किया है (नाम goreuse ) जो कोड बनाने के लिए इस तकनीक का उपयोग करता है और टाइप एलियास रिबाइंडिंग के लिए एक अवधारणा के रूप में पैदा होता है।

यह यहां पाया जा सकता है। एक 15 मिनट का वीडियो है जो टूल की व्याख्या करता है।

@ dc0d तो यह विशेष कार्यान्वयन उत्पन्न करने वाले सी ++ टेम्पलेट्स की तरह काम करता है। मुझे नहीं लगता कि इसे गो टीम के रूप में स्वीकार किया जाएगा (और, स्पष्ट रूप से, मुझे और यहां कई अन्य लोग) सी ++ टेम्पलेट्स के समान कुछ भी नहीं हैं। यह बायनेरिज़ को बढ़ाता है, संकलन को धीमा करता है, संभवतः सार्थक त्रुटियाँ उत्पन्न करने में सक्षम नहीं होगा। और, इसके शीर्ष पर, केवल बाइनरी पैकेज के साथ संगत नहीं है जो गो समर्थन करता है। यही कारण है कि C++ ने हेडर फाइलों में टेम्प्लेट लिखने का विकल्प चुना।

@ क्रेकर

इसलिए यह प्रत्येक प्रयुक्त प्रकार के लिए विशेष कार्यान्वयन उत्पन्न करने वाले सी ++ टेम्पलेट्स की तरह काम करता है।

मुझे नहीं पता (मुझे कोई C++ लिखे हुए लगभग 16 साल हो चुके हैं)। लेकिन आपके स्पष्टीकरण से ऐसा प्रतीत होता है। फिर भी मुझे यकीन नहीं है कि वे समान हैं या कैसे।

मुझे नहीं लगता कि इसे गो टीम के रूप में स्वीकार किया जाएगा (और, स्पष्ट रूप से, मुझे और यहां कई अन्य लोग) सी ++ टेम्पलेट्स के समान कुछ भी नहीं हैं।

निश्चित रूप से यहां हर किसी के पास उनकी प्राथमिकताओं के आधार पर उनकी प्राथमिकताओं के अच्छे कारण हैं। मेरी सूची में सबसे पहले गो 1.x के साथ संगतता है।

यह बायनेरिज़ को बढ़ाता है,

ये हो सकता है।

संकलन धीमा करता है,

मुझे अत्यधिक संदेह है कि (क्योंकि इसे goreuse के साथ अनुभव किया जा सकता है)।

और, इसके शीर्ष पर, केवल बाइनरी पैकेज के साथ संगत नहीं है जो गो समर्थन करता है।

मुझे यकीन नहीं है। क्या जेनरिक को लागू करने के अन्य तरीके इसका समर्थन करते हैं?

संभवतः सार्थक त्रुटियां उत्पन्न करने में सक्षम नहीं होंगे।

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

@dc0d

मैं इसके बारे में थोड़ा सोचता हूं।
इसके अलावा, यह आंतरिक रूप से इंटरफेस पर स्थापित है, आपके उदाहरण में 'टी'

type T=interface{}

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

@ सिघोया मुझे यकीन नहीं है कि मैं समझता हूं कि आपने क्या कहा।

यह आंतरिक रूप से इंटरफेस पर स्थापित है

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

type T = int

और केवल वे प्रकार जिनमें + ऑपरेटर (या - या * ; निर्भर करता है कि क्या उस ऑपरेटर का उपयोग पैकेज के मुख्य भाग में किया जाता है) को एक प्रकार मान के रूप में उपयोग किया जा सकता है जो उस प्रकार के पैरामीटर में बैठता है।

तो यह केवल इंटरफेस नहीं है जिसे टाइप पैरामीटर प्लेस-होल्डर के रूप में उपयोग किया जा सकता है।

लेकिन यह जेनरिक की शुरूआत का संकेत देगा।

यह _is_ गो भाषा में ही जेनरिक को शुरू करने/कार्यान्वयन करने का एक तरीका है।

@dc0d

बहुरूपता प्रदान करने के लिए आप इंटरफ़ेस {} का उपयोग करेंगे क्योंकि यह टी को बाद में किसी भी प्रकार पर सेट करने की अनुमति देता है।

'टाइप टी = इंट' सेट करने से ज्यादा फायदा नहीं होगा।

यदि आप कहेंगे कि 'टाइप टी' पहले अघोषित/अपरिभाषित है जिसे बाद में सेट किया जा सकता है, तो आपके पास जेनरिक जैसा कुछ है।

इसके साथ समस्या यह है कि 'टी' मॉड्यूल/पैकेज चौड़ा रखता है और किसी भी फ़ंक्शन या संरचना के लिए स्थानीय नहीं है (ठीक है, शायद एक संरचना में नेस्टेड प्रकार की घोषणा जिसे बाहर से एक्सेस किया जा सकता है)।

इसके बजाय क्यों नहीं लिख रहे हैं ?:

fun<type T>(t T)

या

fun[type T](t T)

इसके अलावा हमें पहली बार बिना टाइप पैरामीटर विशेषज्ञता के जेनेरिक फ़ंक्शन या स्ट्रक्चर को कॉल करते समय सही प्रकार निकालने के लिए कुछ प्रकार की अनुमान मशीनरी की आवश्यकता होती है।

@dc0d ने लिखा

और केवल वे प्रकार जिनमें + ऑपरेटर होता है (या - या *; निर्भर करता है कि क्या उस ऑपरेटर का उपयोग पैकेज के मुख्य भाग में किया जाता है) का उपयोग उस प्रकार के मान के रूप में किया जा सकता है जो उस प्रकार के पैरामीटर में बैठता है।

क्या आप इस पर और विस्तार से बता सकते हैं?

@ सिघोया

बहुरूपता प्रदान करने के लिए आप इंटरफ़ेस {} का उपयोग करेंगे क्योंकि यह टी को बाद में किसी भी प्रकार पर सेट करने की अनुमति देता है।

बहुरूपता प्रकार के उपनामों को पुन: बाँधने पर संगत प्रकार होने से प्राप्त नहीं होता है। केवल वास्तविक बाधा जेनेरिक पैकेज का मुख्य भाग है। उन्हें यांत्रिक रूप से संगत होना चाहिए।

क्या आप इस पर और विस्तार से बता सकते हैं?

उदाहरण के लिए यदि पैकेज स्तर प्रकार पैरामीटर प्रकार उपनाम को परिभाषित किया गया है:

package genericadd

type T = int

func Add(a, b T) T { return a + b }

फिर वस्तुतः सभी संख्यात्मक प्रकारों को T को सौंपा जा सकता है, जैसे:

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@dc0d

फिर भी मुझे यकीन नहीं है कि वे समान हैं या कैसे।

वे एक ही अर्थ में समान हैं कि वे जो कुछ मैं देखता हूं उससे काफी समान रूप से काम करते हैं। प्रत्येक वर्ग टेम्पलेट के लिए इंस्टेंटेशन कंपाइलर एक अद्वितीय कार्यान्वयन उत्पन्न करेगा यदि यह पहली बार क्लास टेम्पलेट और इसकी पैरामीटर सूची के विशेष संयोजन का उपयोग देखता है। यह द्विआधारी आकार को बढ़ाता है क्योंकि अब आपके पास एक ही वर्ग के टेम्पलेट के कई कार्यान्वयन हैं। संकलक के रूप में धीमी गति से संकलन को अब इन कार्यान्वयनों को उत्पन्न करने और सभी प्रकार की जाँच करने की आवश्यकता होगी। सी ++ के मामले में, संकलन समय में वृद्धि बहुत बड़ी हो सकती है। आपके खिलौनों के उदाहरण तेज़ हैं लेकिन सी ++ वाले भी हैं।

मुझे यकीन नहीं है। क्या जेनरिक को लागू करने के अन्य तरीके इसका समर्थन करते हैं?

अन्य भाषाओं को इससे कोई समस्या नहीं है। विशेष रूप से, सी # मेरे लिए सबसे ज्यादा परिचित है। लेकिन यह रनटाइम कोड जनरेशन का उपयोग करता है जिसे गो टीम पूरी तरह से नियंत्रित करती है। जावा भी काम करता है लेकिन कम से कम कहने के लिए उनका कार्यान्वयन सबसे अच्छा नहीं है। कुछ ianlancetaylor प्रस्ताव जो मैं समझता हूं उससे केवल बाइनरी पैकेज को संभाल सकता है।

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

बस मेरी समझ का परीक्षण करने के लिए ... कॉपी/पेस्ट एल्गोरिदम के इस रेपो पर विचार करें [ यहां ]। जब तक आप "int" का उपयोग नहीं करना चाहते, कोड का सीधे उपयोग नहीं किया जा सकता है। इसे कॉपी और पेस्ट किया जाना चाहिए और काम करने के लिए संशोधित किया जाना चाहिए। और संशोधनों से, मेरा मतलब है कि "int" के प्रत्येक उदाहरण को आपको वास्तव में जिस भी प्रकार की आवश्यकता है उसे बदला जाना चाहिए।

टाइप उपनाम दृष्टिकोण टी कहने के लिए एक बार संशोधन करेगा, और एक पंक्ति "टाइप टी int" डालें। फिर कंपाइलर को टी को किसी और चीज़ से दोबारा जोड़ने की आवश्यकता होगी, फ्लोट 64 कहें।

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

मुझे ऐसा लगता है कि टाइप एलियास और आने वाले वीगो के बीच, जेनरिक के लिए इस दृष्टिकोण की नींव लगभग पूरी हो चुकी है ...

प्रस्ताव में कुछ "अज्ञात" सूचीबद्ध हैं [ यहाँ ]। इसलिए अच्छा होगा कि इसे थोड़ा और बढ़ाया जाए।

@mandolyte आप कुछ सामान्य कंटेनर में विशेष प्रकार लपेटकर एक और स्तर का संकेत जोड़ सकते हैं। इस तरह आपका कार्यान्वयन वही रह सकता है। संकलक तब सभी जादू करेगा। मुझे लगता है कि इयान का प्रकार पैरामीटर प्रस्ताव उसी तरह काम करता है।

मुझे लगता है कि उपयोगकर्ता को टाइप एरर और मोनोमोर्फिज़ेशन के बीच एक विकल्प की आवश्यकता है।
उत्तरार्द्ध यही कारण है कि रस्ट शून्य-लागत अमूर्तता प्रदान करता है। जाना भी चाहिए।

सोम पर, अप्रैल 9, 2018, 8:32 पूर्वाह्न एंटोनेंको आर्टेम नोटिफिकेशन @github.com
लिखा था:

@mandolyte https://github.com/mandolyte आप एक और स्तर जोड़ सकते हैं
कुछ सामान्य कंटेनर में विशेष प्रकार लपेटकर अप्रत्यक्ष। वह
जिस तरह से आपका कार्यान्वयन वही रह सकता है। संकलक तब सब करेगा
जादू। मुझे लगता है कि इयान का प्रकार पैरामीटर प्रस्ताव उसी तरह काम करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-379735199 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWB1v9h5kWmuHCBuoewTTSX751OHgrks5tm1TsgaJpZM4IG-xv
.

मुझे ऐसा लगता है कि मॉड्युलैरिटी और प्रदर्शन के बीच ट्रेडऑफ़ के बारे में इस चर्चा में एक समझने योग्य भ्रम है। हर प्रकार के जेनेरिक कोड को री-टाइप-चेकिंग और इंस्टेंटिनेट करने की C++ तकनीक मॉड्युलैरिटी के लिए खराब है, बाइनरी डिस्ट्रीब्यूशन के लिए खराब है, और कोड ब्लोट के कारण, प्रदर्शन के लिए खराब है। उस दृष्टिकोण का अच्छा हिस्सा यह है कि यह स्वचालित रूप से उपयोग किए जा रहे प्रकारों के लिए जेनरेट कोड को माहिर करता है, जो विशेष रूप से सहायक होता है जब उपयोग किए जा रहे प्रकार int जैसे आदिम प्रकार होते हैं। जावा सजातीय रूप से जेनेरिक कोड का अनुवाद करता है, लेकिन प्रदर्शन में एक कीमत चुकाता है, खासकर जब कोड T[] प्रकार का उपयोग करता है।

सौभाग्य से, सी ++ की गैर-मॉड्यूलरिटी के बिना और पूर्ण रन-टाइम कोड पीढ़ी के बिना इसे संबोधित करने के कुछ तरीके हैं:

1. आदिम प्रकारों के लिए विशेष इंस्टेंटेशन उत्पन्न करें। यह या तो स्वचालित रूप से या प्रोग्रामर निर्देश द्वारा किया जा सकता है। सही इंस्टेंटेशन तक पहुंचने के लिए कुछ प्रेषण की आवश्यकता होती है, लेकिन एक सजातीय अनुवाद के लिए पहले से ही आवश्यक प्रेषण में तब्दील किया जा सकता है। यह C# के समान कार्य करेगा, लेकिन इसके लिए पूर्ण रन-टाइम कोड जनरेशन की आवश्यकता नहीं है; कोड लोड के रूप में डिस्पैच टेबल सेट करने के लिए रनटाइम में थोड़ा अतिरिक्त समर्थन वांछनीय हो सकता है।
2. एक एकल सामान्य कार्यान्वयन का उपयोग करें जिसमें टी की एक सरणी वास्तव में एक आदिम प्रकार की सरणी के रूप में दर्शायी जाती है जब टी को एक आदिम प्रकार के रूप में तत्काल किया जाता है। यह दृष्टिकोण, जिसका उपयोग हमने PolyJ, Genus और Familia में किया था, जावा दृष्टिकोण के सापेक्ष प्रदर्शन में बहुत सुधार करता है, हालांकि यह पूरी तरह से विशेष कार्यान्वयन जितना तेज़ नहीं है।

@dc0d

बहुरूपता प्रकार के उपनामों को पुन: बाँधने पर संगत प्रकार होने से प्राप्त नहीं होता है। केवल वास्तविक बाधा जेनेरिक पैकेज का मुख्य भाग है। उन्हें यांत्रिक रूप से संगत होना चाहिए।

उपनाम टाइप करना गलत तरीका है, क्योंकि यह एक निरंतर संदर्भ होना चाहिए।
सीधे 'टी टाइप' लिखना बेहतर है और फिर आप देखते हैं कि आप वास्तव में जेनरिक का उपयोग करते हैं।

आप पूरे पैकेज/मॉड्यूल के लिए वैश्विक प्रकार चर 'टी' का उपयोग क्यों करना चाहते हैं, <> या [] में स्थानीय प्रकार के संस्करण अधिक मॉड्यूलर हैं।

@ क्रेकर

विशेष रूप से, सी # मेरे लिए सबसे ज्यादा परिचित है। लेकिन यह रनटाइम कोड जनरेशन का उपयोग करता है जिसे गो टीम पूरी तरह से नियंत्रित करती है।

संदर्भ प्रकारों के लिए, लेकिन मान प्रकारों के लिए नहीं।

@DemiMarie

मुझे लगता है कि उपयोगकर्ता को टाइप एरर और मोनोमोर्फिज़ेशन के बीच एक विकल्प की आवश्यकता है।
उत्तरार्द्ध यही कारण है कि रस्ट शून्य-लागत अमूर्तता प्रदान करता है। जाना भी चाहिए।

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

जाओ जावा वे जाने की जरूरत नहीं है क्योंकि:

"रिलीज़ के बीच संकलित पैकेजों के लिए बाइनरी संगतता की गारंटी नहीं है"

जबकि जावा में यह संभव नहीं है।

मुझे ऐसा लगता है कि मॉड्युलैरिटी और प्रदर्शन के बीच ट्रेडऑफ़ के बारे में इस चर्चा में एक समझने योग्य भ्रम है। हर प्रकार के जेनेरिक कोड को री-टाइप-चेकिंग और इंस्टेंटिनेट करने की C++ तकनीक मॉड्युलैरिटी के लिए खराब है, बाइनरी डिस्ट्रीब्यूशन के लिए खराब है, और कोड ब्लोट के कारण, प्रदर्शन के लिए खराब है।

आप यहां किस तरह के प्रदर्शन की बात कर रहे हैं?

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

यदि "कोड ब्लोट" और "प्रदर्शन" से आपका मतलब "लिंकर इनपुट आकार" और "लिंकिंग समय" से है, तो समस्या भी काफी सीधी है, यदि आप अपने निर्माण प्रणाली के बारे में कुछ (उचित) धारणाएं बना सकते हैं। प्रत्येक संकलन इकाई में प्रत्येक विशेषज्ञता का उत्सर्जन करने के बजाय, आप इसके बजाय आवश्यक विशेषज्ञताओं की एक सूची जारी कर सकते हैं, और बिल्ड सिस्टम को जोड़ने से ठीक पहले प्रत्येक अद्वितीय विशेषज्ञता को तुरंत चालू कर सकते हैं ("सीफ़्रंट मॉडल")। IIRC, यह उन समस्याओं में से एक है जिसे C++ मॉड्यूल संबोधित करने का प्रयास करते हैं।

इसलिए जब तक आपका मतलब तीसरे प्रकार के "कोड ब्लोट" और "प्रदर्शन" से है जो मैंने याद किया है, ऐसा लगता है कि आप कार्यान्वयन के साथ एक समस्या के बारे में बात कर रहे हैं, विनिर्देश नहीं: _ जब तक कार्यान्वयन डीबग को ओवर-रिटेन नहीं करता है जानकारी,_ प्रदर्शन के मुद्दों को संबोधित करने के लिए काफी सरल हैं।

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

यह वास्तव में प्रतिरूपकता की विफलता है, लेकिन इसका कोड ब्लोट से कोई लेना-देना नहीं है: इसके बजाय, यह इस तथ्य से आता है कि गो फ़ंक्शन (और विधियाँ) के प्रकार अपने तर्कों पर बाधाओं के एक पूर्ण सेट पर कब्जा नहीं करते हैं।

@ सिघोया

संदर्भ प्रकारों के लिए, लेकिन मान प्रकारों के लिए नहीं।

मैंने जो पढ़ा है, उससे सी # जेआईटी प्रत्येक मान प्रकार के लिए रनटाइम पर और एक बार सभी संदर्भ प्रकारों के लिए विशेषज्ञता प्राप्त करता है। कोई संकलन-समय (IL-time) विशेषज्ञता नहीं है। यही कारण है कि सी # दृष्टिकोण को पूरी तरह से नजरअंदाज कर दिया गया है - गो टीम रनटाइम कोड जनरेशन पर निर्भर नहीं होना चाहती क्योंकि यह प्लेटफॉर्म को सीमित करती है, जिस पर गो चल सकता है। विशेष रूप से, आईओएस पर आपको रनटाइम पर कोड जनरेशन करने की अनुमति नहीं है। यह काम करता है और मैंने वास्तव में इसमें से कुछ किया है लेकिन ऐप्पल इसे ऐपस्टोर में अनुमति नहीं देता है।

तुमने ये कैसे किया?

सोम पर, अप्रैल 9, 2018, 3:41 अपराह्न एंटोनेंको आर्टेम नोटिफिकेशन @github.com
लिखा था:

@सिघोया https://github.com/sighoya

संदर्भ प्रकारों के लिए, लेकिन मान प्रकारों के लिए नहीं।

मैंने जो पढ़ा है, उससे C# JIT प्रत्येक मान के लिए रनटाइम पर विशेषज्ञता प्राप्त करता है
सभी संदर्भ प्रकारों के लिए टाइप करें और एक बार। कोई संकलन-समय नहीं है
विशेषज्ञता। यही कारण है कि सी # दृष्टिकोण को पूरी तरह से नजरअंदाज कर दिया गया है - टीम जाओ
रनटाइम कोड जनरेशन पर निर्भर नहीं होना चाहता क्योंकि यह प्लेटफॉर्म को सीमित करता है
पर चल सकता है। विशेष रूप से, iOS पर आपको कोड जनरेशन करने की अनुमति नहीं है
चलने के समय पर। यह काम करता है और मैंने वास्तव में इसमें से कुछ किया है लेकिन Apple अनुमति नहीं देता है
इसे ऐपस्टोर में।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-379870005 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWB-tslGeUSGXl2ZlEDLf0dCATUaYvks5tm7lvgaJpZM4IG-xv
.

@DemiMarie ने मेरा पुराना शोध कोड केवल यह सुनिश्चित करने के लिए लॉन्च किया (वह शोध अन्य कारणों से हटा दिया गया था)। एक बार फिर, डीबगर ने मुझे गुमराह किया। मैं एक पृष्ठ आवंटित करता हूं, उस पर कुछ निर्देश लिखता हूं, इसे PROT_EXEC से सुरक्षित करता हूं और उस पर कूद जाता हूं। डीबगर के तहत यह काम करता है। डिबगर ऐप के बिना क्रैश लॉग में कोडसाइन संदेश के साथ सिगकिल किया जाता है, जैसा कि अपेक्षित था। तो, यह AppStore के बिना भी काम नहीं करता है। यदि आईओएस गो के लिए महत्वपूर्ण है तो रनटाइम कोड जनरेशन के खिलाफ और भी मजबूत तर्क।

सबसे पहले, रॉब पाइक के प्रोग्रामिंग के 5 नियमों पर एक बार फिर से विचार करना मददगार होगा।

दूसरा (आईएमएचओ):

धीमी गति से संकलन और बाइनरी आकार के बारे में, सामान्य प्रकार के अनुप्रयोगों में कितने सामान्य प्रकारों का उपयोग किया जाता है जिन्हें गो का उपयोग करके विकसित किया जा रहा है (_n आमतौर पर नियम 3 से छोटा_ है)? जब तक समस्या को ठोस अवधारणाओं (उच्च संख्या में प्रकार) में उच्च स्तर की कार्डिनैलिटी की आवश्यकता नहीं होती है, तब तक ओवरहेड को अनदेखा किया जा सकता है। फिर भी मैं तर्क दूंगा कि उस दृष्टिकोण में कुछ गड़बड़ है। ई-कॉमर्स प्रणाली को लागू करते समय, कोई भी प्रत्येक प्रकार के उत्पाद के लिए एक अलग प्रकार को परिभाषित नहीं करता है और इसकी विविधताएं और शायद संभावित अनुकूलन।

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

मुझे समझ में नहीं आता कि यह प्रदर्शन को कैसे नुकसान पहुंचा सकता है क्योंकि रनटाइम पर, केवल ठोस बाध्य प्रकारों का उपयोग किया जा रहा है जो संकलन-समय पर उत्पन्न हुए थे। कोई रनटाइम ओवरहेड नहीं है।

टाइप एलियास रीबाइंडिंग के साथ एकमात्र चिंता जो मुझे दिखाई देती है, वह बाइनरी वितरण हो सकती है।

@ dc0d प्रदर्शन हानि का अर्थ आमतौर पर क्लास टेम्प्लेट के विभिन्न कार्यान्वयन के कारण निर्देश कैश भरना होता है। यह वास्तविक प्रदर्शन से वास्तव में कैसे संबंधित है यह एक खुला प्रश्न है, मुझे किसी भी मानक के बारे में पता नहीं है, लेकिन सैद्धांतिक रूप से यह एक समस्या है।

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

टाइप एलियास रीबाइंडिंग के साथ एकमात्र चिंता जो मुझे दिखाई देती है, वह बाइनरी वितरण हो सकती है।

यहाँ मुझे अभी भी यकीन नहीं है। क्या जेनरिक प्रस्ताव को बाइनरी-ओनली पैकेज का समर्थन करना है या हम केवल यह उल्लेख कर सकते हैं कि बाइनरी-ओनली पैकेज जेनरिक का समर्थन नहीं करते हैं। यह बहुत आसान होगा, यह पक्का है।

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

मंगलवार को, अप्रैल 10, 2018, 5:46 पूर्वाह्न केव शाहबाजियन नोटिफिकेशन @github.com
लिखा था:

सबसे पहले, रॉब पाइक के प्रोग्रामिंग के 5 नियमों पर विचार करना मददगार होगा
https://users.ece.utexas.edu/%7Eadnan/pike.html एक बार और।

दूसरा (आईएमएचओ):

धीमी गति से संकलन और बाइनरी आकार के बारे में, कितने सामान्य प्रकारों का उपयोग किया जाता है
सामान्य प्रकार के अनुप्रयोग जो गो ( n is . ) का उपयोग करके विकसित किए जा रहे हैंआमतौर पर छोटा ? जब तक समस्या को उच्च स्तर की आवश्यकता न हो
ठोस अवधारणाओं में कार्डिनैलिटी (उच्च संख्या में प्रकार) जो ओवरहेड कर सकते हैं
अनदेखी की जाए। फिर भी मैं तर्क दूंगा कि इसमें कुछ गड़बड़ है
पहुंचना। ई-कॉमर्स प्रणाली को लागू करते समय, कोई भी अलग से परिभाषित नहीं करता है
प्रत्येक प्रकार के उत्पाद के लिए टाइप करें और इसकी विविधताएं और शायद संभव
अनुकूलन।

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

मुझे समझ में नहीं आता कि यह प्रदर्शन को कैसे नुकसान पहुंचा सकता है क्योंकि केवल रनटाइम पर
कंक्रीट बाउंडेड प्रकारों का उपयोग किया जा रहा है जो कि उत्पन्न किए गए थे
संकलन-समय। कोई रनटाइम ओवरहेड नहीं है।

टाइप एलियास रीबाइंडिंग के साथ एकमात्र चिंता जो मुझे दिखाई दे रही है, वह बाइनरी हो सकती है
वितरण।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-380040032 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWB6aDfoHz2wbsmu8mCGEt652G_VE9ks5tnH9xgaJpZM4IG-xv
.

तात्कालिकता को "समान तर्कों का उपयोग करना", या यहां तक ​​​​कि "उसी अंतर्निहित प्रकार के साथ तर्कों का उपयोग करना" के अर्थ में "समान" होने की आवश्यकता नहीं है। उन्हें समान जनरेट किए गए कोड में परिणाम के लिए बस इतना करीब होना चाहिए। (गो के लिए, इसका अर्थ "वही पॉइंटर मास्क" भी है।)

@ क्रेकर

मैंने जो पढ़ा है, उससे सी # जेआईटी प्रत्येक मान प्रकार के लिए रनटाइम पर और एक बार सभी संदर्भ प्रकारों के लिए विशेषज्ञता प्राप्त करता है। कोई संकलन-समय (IL-time) विशेषज्ञता नहीं है।

खैर, यह कभी-कभी थोड़ा जटिल होता है क्योंकि उनके बाइट कोड की व्याख्या कोड निष्पादित होने से ठीक पहले की जाती है, इसलिए कोड जनरेशन प्रोग्राम को निष्पादित करने से पहले किया जाता है, लेकिन संकलन के बाद, इसलिए आप vm के अर्थ में सही हैं जो कोड के दौरान चल रहा है उत्पन्न होता है।

मुझे लगता है कि सी # की सामान्य प्रणाली जाने के लिए ठीक होगी यदि हम इसके बजाय संकलन समय पर कोड उत्पन्न करते हैं।
सी # के अर्थ में रनटाइम कोड जनरेशन गो के साथ संभव नहीं है, क्योंकि गो एक वीएम नहीं है।

@dc0d

टाइप एलियास रीबाइंडिंग के साथ एकमात्र चिंता जो मुझे दिखाई देती है, वह बाइनरी वितरण हो सकती है।

क्या आप थोड़ा विस्तार कर सकते हैं।

@ सिघोया मेरी गलती; मेरा मतलब बाइनरी डिस्ट्रीब्यूशन नहीं बल्कि बाइनरी पैकेज था - जो व्यक्तिगत रूप से मुझे नहीं पता कि यह कितना महत्वपूर्ण है।

@creker अच्छा योग! (एमओ) जब तक कोई मजबूत कारण नहीं मिल जाता है, गो भाषा निर्माणों के किसी भी प्रकार के ओवरलोडिंग से बचा जाना चाहिए। टाइप एलियास रिबाइंडिंग के साथ जाने का एक कारण स्लाइस या मैप्स जैसे बिल्ट-इन कंपोजिट प्रकारों को ओवरलोड करने से बचना है।

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

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

नामों की तीन श्रेणियां हैं जिन्हें हमें दैनिक आधार पर तैयार करना है:

• डोमेन संस्थाओं/तर्क के लिए
• प्रोग्राम वर्कफ़्लो डेटा प्रकार/तर्क
• सेवाएं/इंटरफेसिंग डेटा प्रकार/तर्क

कितनी बार एक प्रोग्रामर अपने कोड में कुछ भी नाम देने से बचने में सफल रहा है?

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

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

वाक्य रचना और वाचालता के लिए, मैं चतुर संक्षिप्तता (कम से कम गो के संदर्भ में) पर वाचालता का पक्ष लेता हूं - फिर से, गो को पढ़ने में आसान होना चाहिए, जरूरी नहीं कि लिखना आसान हो (जो अजीब तरह से मुझे उस पर भी अच्छा लगता है) .

@jba देखें https://github.com/golang/go/issues/8303 और https://github.com/golang/go/issues/8082

मैंने गो में जेनरिक को क्यों और कैसे लागू किया जाए, इस पर कई अनुभव रिपोर्ट और प्रस्ताव पढ़े।

क्या आपको बुरा लगता है अगर मैं वास्तव में उन्हें अपने गो दुभाषिया गोमैक्रो में लागू करने का प्रयास करता हूं?

मुझे इस विषय पर कुछ अनुभव है, अतीत में दो भाषाओं में जेनरिक जोड़ चुका हूं

1. अब एक परित्यक्त भाषा जिसे मैंने तब बनाया जब मैं भोली थी :) यह सी स्रोत कोड में स्थानांतरित हो गई
2. मेरी लाइब्रेरी सीएल-पैरामीट्रिक-प्रकार के साथ सामान्य लिस्प - यह सामान्य प्रकार और कार्यों के आंशिक और पूर्ण विशेषज्ञता का भी समर्थन करता है

@ cosmos72 यह एक ऐसी तकनीक के प्रोटोटाइप को देखने के लिए एक अच्छा अनुभव रिपोर्ट बनाएगा जो संरक्षित प्रकार की सुरक्षा है।

अभी इस पर काम करना शुरू किया है। आप https://github.com/cosmos72/gomacro/tree/generics-v1 पर प्रगति का अनुसरण कर सकते हैं

फिलहाल मैं https://github.com/golang/proposal/blob/master/design/15292-generics.md#Proposal पर सूचीबद्ध तीसरे और चौथे इयान के प्रस्ताव के एक (थोड़ा संशोधित) मिश्रण के साथ शुरुआत कर रहा हूं।

@cosmos72 नीचे दिए गए लिंक पर प्रस्तावों का सारांश है। क्या आपका मिश्रण उनमें से एक है?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

मैंने उस दस्तावेज़ को पढ़ा है, यह विभिन्न प्रोग्रामिंग भाषाओं द्वारा जेनरिक के लिए कई अलग-अलग दृष्टिकोणों को सारांशित करता है।

फिलहाल मैं सी ++, रस्ट और अन्य द्वारा उपयोग की जाने वाली "टाइप स्पेशलाइजेशन" तकनीक की ओर जा रहा हूं, संभवतः "पैरामीटरेटेड टेम्पलेट स्कोप" के साथ, क्योंकि नए प्रकारों के लिए सबसे सामान्य सिंटैक्स type ( Foo ...; Bar ...) है और मैं विस्तार कर रहा हूं यह करने के लिए template[T1,T2...] type ( Foo ...; Bar ...) ।
इसके अलावा, मैं "विवश विशेषज्ञता" के लिए दरवाजा खुला रख रहा हूं।

मैं "पॉलीमॉर्फिक फ़ंक्शन विशेषज्ञता" को भी लागू करना चाहता हूं, यानी प्रोग्रामर द्वारा निर्दिष्ट नहीं होने पर कॉल साइट पर भाषा द्वारा स्वचालित रूप से अनुमानित विशेषज्ञता की व्यवस्था करने के लिए, लेकिन मुझे लगता है कि इसे लागू करने के लिए कुछ जटिल हो सकता है। हम देख लेंगे।

मैं जिस मिश्रण की बात कर रहा था वह https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md और https://github.com/golang/proposal/blob/ के बीच है।

अद्यतन: प्रारंभिक घोषणा से परे इस आधिकारिक गो मुद्दे को स्पैमिंग से बचने के लिए, संभवतः गोमैक्रो मुद्दे #24 पर गोमैक्रो-विशिष्ट चर्चा जारी रखना बेहतर है: जेनरिक जोड़ें

अद्यतन 2: पहला टेम्पलेट फ़ंक्शन संकलित और सफलतापूर्वक निष्पादित किया गया। देखें https://github.com/cosmos72/gomacro/tree/generics-v1

सिर्फ रिकॉर्ड के लिए, मेरी राय को फिर से लिखना संभव है (जेनेरिक और टाइप एलियास रीबाइंडिंग पर):

जेनरिक को एक कंपाइलर फीचर (कोड जनरेशन, टेम्प्लेट, आदि) के रूप में जोड़ा जाना चाहिए, न कि एक भाषा फीचर (सभी स्तरों पर गो के टाइप सिस्टम के साथ दखल)।

@dc0d
लेकिन क्या C++ टेम्प्लेट कंपाइलर और लैंग्वेज फीचर नहीं हैं?

@ सिघोया पिछली बार जब मैंने पेशेवर रूप से सी ++ लिखा था तो 2001 के आसपास था। तो मैं गलत हो सकता हूं। लेकिन यह मानते हुए कि नामकरण के निहितार्थ सटीक हैं - "टेम्पलेट" भाग - हाँ (या यों कहें कि नहीं); यह कुछ भाषा संरचनाओं के साथ एक संकलक सुविधा (और एक भाषा सुविधा नहीं) हो सकती है, जो कि सबसे अधिक संभावना है कि टाइप सिस्टम में शामिल किसी भी भाषा निर्माण को ओवरलोड नहीं कर रहे हैं।

मैं @dc0d का समर्थन करता हूं। यदि आप इस पर विचार करते हैं, तो यह सुविधा एक एकीकृत कोड जनरेटर से ज्यादा कुछ नहीं होगी।

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

type BinaryTreeOfStrings struct {
    left, right *BinaryTreeOfStrings;
    string content;
}

// Its methods here

type BinaryTreeOfBigInts struct {
    left, right *BinaryTreeOfBigInts;
    uint64 content;
}

// AGAIN the same methods but different type

... मैं गंभीरता से चाहूंगा कि कॉपी पेस्ट करने या किसी बाहरी टूल का उपयोग करने के बजाय, यह सुविधा कंपाइलर का ही हिस्सा बन जाए।

कृपया ध्यान दें:

• हां, अंतिम कोड दोहराया जाएगा। ठीक वैसे ही जैसे हम जेनरेटर का इस्तेमाल करते हैं। और बाइनरी बड़ा होगा।
• हां, विचार मूल नहीं है, लेकिन C++ से उधार लिया गया है।
• हाँ, MyType के कार्यT (प्रत्यक्ष या परोक्ष रूप से) प्रकार के साथ कुछ भी शामिल नहीं होने पर भी दोहराया जाएगा। इसे अनुकूलित किया जा सकता है (उदाहरण के तरीके जो T प्रकार के कुछ को संदर्भित करते हैं-संदेश प्राप्त करने वाले ऑब्जेक्ट के सूचक के अलावा- प्रत्येक T के लिए जेनरेट किए जाएंगे; विधियों के लिए आमंत्रण रखने वाली विधियां प्रत्येक T के लिए उत्पन्न किया जाएगा, प्रत्येक T के लिए भी पुनरावर्ती रूप से उत्पन्न किया जाएगा - जबकि वे विधियां जहां T का उनका एकमात्र संदर्भ रिसीवर में *T है, और अन्य विधियां केवल उन सुरक्षित विधियों को बुलाकर और समान मानदंडों को पूरा करने वाली, केवल एक बार बनाई जा सकती हैं)। वैसे भी, IMO यह बिंदु बड़ा है और इस बिंदु से कम है: मुझे बहुत खुशी होगी, भले ही यह अनुकूलन मौजूद न हो।
• मेरी राय में प्रकार के तर्क स्पष्ट होने चाहिए। विशेष रूप से जब कोई वस्तु संभावित अनंत इंटरफेस को संतुष्ट करती है। दोबारा: एक कोड जनरेटर।

अब तक मेरी टिप्पणी में, मेरा प्रस्ताव इसे इस रूप में लागू करना है: एक बाहरी उपकरण के बजाय एक कंपाइलर-समर्थित कोड जनरेटर के रूप में।

गो के लिए C++ मार्ग का अनुसरण करना दुर्भाग्यपूर्ण होगा। बहुत से लोग सी ++ दृष्टिकोण को एक गड़बड़ी के रूप में देखते हैं जिसने प्रोग्रामर को जेनेरिक के पूरे विचार के खिलाफ बदल दिया है: डिबगिंग की कठिनाई, मॉड्यूलरिटी की कमी, कोड ब्लोट। सभी "कोड जनरेटर" समाधान वास्तव में केवल मैक्रो प्रतिस्थापन हैं - यदि आप इस तरह से कोड लिखना चाहते हैं, तो हमें कंपाइलर समर्थन की भी आवश्यकता क्यों है?

@andrewcmyers मेरे पास यह प्रस्ताव टाइप एलियास रिबाइंडिंग था जिसमें हम केवल सामान्य पैकेज लिखते हैं और interface{} स्पष्ट रूप से उपयोग करने के बजाय हम इसे केवल type T = interface{} के रूप में पैकेज-स्तरीय जेनेरिक पैरामीटर के रूप में उपयोग करते हैं। और बस यही।

• हम इसे एक सामान्य पैकेज की तरह डिबग करते हैं - यह वास्तविक कोड है, न कि कुछ मध्यवर्ती अर्ध-जीवन प्राणी।
• सभी स्तरों पर गो टाइप सिस्टम के साथ हस्तक्षेप करने की कोई आवश्यकता नहीं है - अकेले असाइनमेंट के बारे में सोचें।
• यह स्पष्ट है। कोई छिपा हुआ मोजो नहीं। निश्चित रूप से कोई व्यक्ति जेनेरिक कॉलों को मूल रूप से श्रृंखलाबद्ध करने में सक्षम नहीं हो सकता है, यह एक खामी है। मैं इसे ड्रॉ-फॉरवर्ड के रूप में देखता हूं! लगातार दो कॉलों में टाइप बदलना, एक स्टेटमेंट में गोइश (आईएमओ) नहीं है।
• और सबसे अच्छी बात यह है कि यह गो 1.x (x>= 8) श्रृंखला के साथ पिछड़ा संगत है।

हालांकि यह विचार नया नहीं है, गो जिस तरह से इसे लागू करने की अनुमति देता है, वह व्यावहारिक और स्पष्ट है।

इसके अलावा बोनस: गो में कोई ऑपरेटर ओवरलोडिंग नहीं है। लेकिन प्रकार के उपनाम के डिफ़ॉल्ट मान को परिभाषित करके (उदाहरण के लिए) type T = int , न कि केवल मान्य प्रकार जिनका उपयोग इस सामान्य पैकेज को अनुकूलित करने के लिए किया जा सकता है, संख्यात्मक प्रकार हैं जिनका आंतरिक कार्यान्वयन + है

इसके अलावा उपनाम प्रकार पैरामीटर को केवल कुछ सत्यापनकर्ता प्रकार और कथन जोड़कर एक से अधिक इंटरफ़ेस को पूरा करने के लिए मजबूर किया जा सकता है।

अब, यह एक सामान्य प्रकार के लिए किसी भी स्पष्ट संकेतन का उपयोग करके सुपर बदसूरत होगा जिसमें एक पैरामीटर है जो Error और Stringer इंटरफेस को लागू करता है और यह एक संख्यात्मक प्रकार भी है जो + ऑपरेटर का समर्थन करता है !

अभी हम कोड जेनरेटर का उपयोग करते हैं, जो काफी हद तक एक जैसे हैं लेकिन बाहरी फीचर के रूप में हैं।

अंतर यह है कि कोड जनरेशन करने का व्यापक रूप से स्वीकृत तरीका ( go generate के माध्यम से) प्रतिबद्ध/विकास समय पर होता है, संकलन समय पर नहीं। संकलन समय पर ऐसा करने का तात्पर्य है कि आपको संकलक में मनमाने ढंग से कोड निष्पादन की अनुमति देने की आवश्यकता है, पुस्तकालय परिमाण के आदेश से संकलन समय उड़ा सकते हैं और/या आपके पास अलग-अलग निर्माण निर्भरताएं होंगी (यानी कोड अब केवल गो के साथ नहीं बनाया जा सकता है उपकरण)। मुझे अपस्ट्रीम डेवलपर को मेटा-प्रोग्रामिंग के आह्वान को आगे बढ़ाने के लिए जाना पसंद है।

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

मैं उपरोक्त सभी चीजें पढ़ूंगा, मैं वादा करता हूं, और फिर भी मैं थोड़ा सा भी जोड़ूंगा - अपाचे बीम के लिए गोलैंग एसडीके बल्कि उज्ज्वल उदाहरण/परेशानी का प्रदर्शन पुस्तकालय डिजाइनर को कुछ भी खींचने के लिए सहन करना पड़ता है _properly_ उच्च स्तर।

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

हालांकि इस कार्यान्वयन ने पैकेज स्तर के दृष्टिकोण को लागू नहीं किया, लेकिन ऐसा करना निश्चित रूप से स्वाभाविक होगा। और, ज़ाहिर है, इस कार्यान्वयन ने सभी तकनीकी विवरणों को संबोधित नहीं किया जहां संकलक तत्काल कोड जाना चाहिए (यदि कहीं भी), कोड डिबगर्स कैसे काम करेंगे, आदि।

पूर्णांकों के लिए समान एल्गोरिथम कोड का उपयोग करना और पॉइंट जैसा कुछ करना काफी अच्छा था:

type Point struct {
    x,y int
}

मेरे परीक्षण और टिप्पणियों के लिए (2) देखें।

(1) https://github.com/albrow/fo; दूसरा उपरोक्त है https://github.com/cosmos72/gomacro#generics
(2) https://github.com/mandolyte/fo-experiments

@mandolyte आप किसी भी प्रकार का शून्य मान प्राप्त करने के लिए *new(T) का उपयोग कर सकते हैं।

डिफ़ॉल्ट (टी) या शून्य (टी) की तरह एक भाषा का निर्माण (पहला वाला एक है
C# IIRC में) स्पष्ट होगा, लेकिन OTOH *new(T) से अधिक लंबा (हालांकि अधिक .)
प्रदर्शन करने वाला)।

2018-07-06 9:15 GMT-05:00 टॉम थोरोगूड नोटिफिकेशन @github.com :

@mandolyte https://github.com/mandolyte आप इसे प्राप्त करने के लिए *new(T) का उपयोग कर सकते हैं
किसी भी प्रकार का शून्य मान।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-403046735 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
.

--
ट्रिपलमिंट में उपयोग किए जाने वाले मेल हस्ताक्षरों के लिए यह एक परीक्षण है

19642 एक सामान्य शून्य मान पर चर्चा करने के लिए है

@tmthrgd किसी तरह मैं उस छोटी सी बात से चूक गया। धन्यवाद!

प्रस्तावना

जेनरिक सभी अनुकूलन योग्य निर्माणों में विशेषज्ञता के बारे में हैं। विशेषज्ञता की तीन श्रेणियां हैं:

• विशेषज्ञता प्रकार, Type<T> - एक _array_;
• विशेषज्ञता गणना, F<T>(T) या F<T>(Type<T>) - एक _sortable array_;
• विशिष्ट नोटेशन, उदाहरण के लिए _LINQ_ - select या for कथन गो में;

बेशक ऐसी प्रोग्रामिंग भाषाएँ हैं जो और भी अधिक सामान्य निर्माण प्रस्तुत करती हैं। लेकिन पारंपरिक प्रोग्रामिंग भाषाएं जैसे _C++_, _C#_ या _Java_ कमोबेश इस सूची तक सीमित भाषा निर्माण प्रदान करती हैं।

विचारों

सामान्य प्रकार/निर्माण की पहली श्रेणी प्रकार अज्ञेयवादी होनी चाहिए।

सामान्य प्रकार/निर्माण की दूसरी श्रेणी को प्रकार पैरामीटर के _property_ पर _act_ की आवश्यकता होती है। उदाहरण के लिए एक _sortable array_ को अपने आइटम्स की _comparable properties_ _compare_ करने में सक्षम होना चाहिए। मान लें कि T.(P) T की संपत्ति है और A(T.(P)) एक गणना/क्रिया है जो उस संपत्ति पर कार्य करती है, (A, .(P)) प्रत्येक व्यक्तिगत आइटम पर लागू किया जा सकता है या एक विशेष गणना के रूप में घोषित किया जा सकता है, मूल अनुकूलन गणना के लिए पारित किया जा सकता है। गो में बाद के मामले का एक उदाहरण sort.Interface इंटरफ़ेस है जिसमें समकक्ष अलग फ़ंक्शन sort.Reverse भी है।

सामान्य प्रकार/निर्माणों की तीसरी श्रेणी _टाइप-विशिष्ट_ भाषा संकेतन हैं - ऐसा लगता है कि यह सामान्य बात नहीं है।

प्रशन

करने के लिए जारी ...

इमोजी की तुलना में अधिक वर्णनात्मक किसी भी प्रतिक्रिया का स्वागत है!

@ dc0d मैं जेनरिक को परिभाषित करने का प्रयास करने से पहले सेपानोव के "एलिमेंट्स ऑफ प्रोग्रामिंग" का अध्ययन करने की सलाह दूंगा। टीएल; डीआर हम शुरू करने के लिए ठोस कोड लिखते हैं, एक एल्गोरिदम कहें जो एक सरणी को टाइप करता है। बाद में हम अन्य संग्रह प्रकार जैसे Btree, आदि जोड़ते हैं। हम देखते हैं कि हम सॉर्ट एल्गोरिथम की कई प्रतियां लिख रहे हैं जो अनिवार्य रूप से समान हैं, इसलिए हम कुछ अवधारणा को परिभाषित करते हैं, जैसे 'क्रमबद्ध'। अब हम सॉर्ट एल्गोरिदम को वर्गीकृत करना चाहते हैं, हो सकता है कि उन्हें एक्सेस पैटर्न की आवश्यकता हो, केवल फॉरवर्ड कहें, सिंगल पास (एक स्ट्रीम), केवल मल्टीपल पास (एक सिंगल लिंक्ड लिस्ट), द्विदिश (एक डबल लिंक्ड लिस्ट), रैंडम एक्सेस (एक) सरणी)। जब हम एक नया संग्रह प्रकार जोड़ते हैं तो हमें केवल यह इंगित करने की आवश्यकता होती है कि यह सभी प्रासंगिक सॉर्ट एल्गोरिदम तक पहुंच प्राप्त करने के लिए "समन्वय" की किस श्रेणी में आता है। ये एल्गोरिदम श्रेणियां 'गो' इंटरफेस की तरह हैं। मैं कई प्रकार के पैरामीटर, और सार/संबद्ध प्रकारों का समर्थन करने के लिए गो में इंटरफेस का विस्तार करना चाहता हूं। मुझे नहीं लगता कि कार्यों को तदर्थ प्रकार के मानकीकरण की आवश्यकता है।

@ dc0d जेनरिक को घटक भागों में तोड़ने के प्रयास के रूप में मैंने पहले 3, "विशेषज्ञ अंकन" को अपना अलग हिस्सा नहीं माना था। शायद इसे प्रकार की बाधाओं का उपयोग करके डीएसएल को परिभाषित करने के रूप में वर्णित किया जा सकता है।

मैं तर्क दे सकता हूं कि आपका 1 और 2 क्रमशः "डेटा संरचनाएं" और "एल्गोरिदम" हैं। उस शब्दावली के साथ यह थोड़ा स्पष्ट है कि उन्हें स्पष्ट रूप से अलग करना मुश्किल क्यों हो सकता है, क्योंकि वे अक्सर एक दूसरे पर अत्यधिक निर्भर होते हैं। लेकिन सॉर्ट करें। इंटरफेस एक बहुत अच्छा उदाहरण है जहां आप भंडारण और व्यवहार के बीच एक रेखा खींच सकते हैं (इसे हाल ही में चीनी के साथ इसे अच्छा बनाने के लिए), क्योंकि यह सॉर्ट एल्गोरिदम को लागू करने के लिए आवश्यक न्यूनतम व्यवहार में इंडेक्सेबल और तुलनात्मक आवश्यकताओं को एन्कोड करता है "स्वैप" और "कम" (और लेन) के साथ। लेकिन ऐसा लगता है कि पेड़ या ढेर जैसे अधिक जटिल डेटा संरचनाओं पर टूट गया है, जिनमें से दोनों वर्तमान में गो इंटरफेस के रूप में शुद्ध व्यवहार में मैप करने के लिए कुछ विरोधाभास लेते हैं।

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

बाइनरी पेड़ों के लिए @infogulch समन्वय संरचनाएं "द्विभाजित निर्देशांक" हैं, और समकक्ष अन्य पेड़ों के लिए मौजूद हैं। हालाँकि आप तीन ऑर्डर, प्री-ऑर्डर, इन-ऑर्डर और पोस्ट-ऑर्डर में से एक के माध्यम से एक पेड़ के ऑर्डरिंग को भी प्रोजेक्ट कर सकते हैं। इनमें से किसी एक पर निर्णय लेने के बाद पेड़ को एक द्विदिश समन्वय के रूप में संबोधित किया जा सकता है, और द्विदिश निर्देशांक पर परिभाषित सॉर्ट एल्गोरिदम का परिवार बेहतर रूप से कुशल होगा।

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

(IMHO)

@infogulch

शायद इसे प्रकार की बाधाओं का उपयोग करके डीएसएल को परिभाषित करने के रूप में वर्णित किया जा सकता है

तुम सही हो। लेकिन चूंकि वे भाषा निर्माण के सेट का हिस्सा हैं, इसलिए आईएमओ उन्हें डीएसएल बुलाना थोड़ा गलत होगा।

1 और 2 ... अक्सर अत्यधिक निर्भर होते हैं

फिर सच। लेकिन ऐसे कई मामले हैं जहां एक कंटेनर प्रकार को पारित करने की आवश्यकता होती है, जबकि वास्तविक उपयोग अभी तक तय नहीं किया गया है - उस समय एक कार्यक्रम में। इसलिए 1 का अध्ययन स्वयं करने की आवश्यकता है।

sort.Interface एक बहुत अच्छा उदाहरण है जहां आप _storage_ और _behavior_ के बीच एक रेखा खींच सकते हैं

खूब कहा है;

ऐसा लगता है कि यह अधिक जटिल डेटा संरचनाओं पर टूट गया है

यह मेरे प्रश्नों में से एक है: प्रकार पैरामीटर को सामान्यीकृत करने के लिए और प्रतिबंधों के संदर्भ में इसका वर्णन करने के लिए (जैसे List<T> where T:new, IDisposable ) या एक सामान्यीकृत _protocol_ प्रदान करने के लिए सभी वस्तुओं (एक सेट के; एक निश्चित प्रकार के) पर लागू होता है?

@ कीन

प्रश्न यह हो जाता है कि आपके पास मौजूद डेटा-संरचनाओं के लिए सॉर्ट एल्गोरिदम के उपलब्ध डेटा-एक्सेस-पैटर्न वर्गीकरणों में से कौन सा इष्टतम है

सत्य। अनुक्रमणिका द्वारा एक्सेस करना एक स्लाइस (या सरणी) का _property_ है। तो एक सॉर्ट करने योग्य कंटेनर (या _tree_-सक्षम कंटेनर जो भी _tree_ एल्गोरिदम है) के लिए पहली आवश्यकता एक _access और mutate (स्वैप) _ उपयोगिता प्रदान करना है। दूसरी आवश्यकता यह है कि आइटम तुलनीय होने चाहिए। यह भ्रमित करने वाला हिस्सा है (मेरे लिए) जिसे आप एल्गोरिदम कहते हैं: आवश्यकताओं को दोनों तरफ (कंटेनर पर और प्रकार पैरामीटर पर) पूरा किया जाना चाहिए। यही वह बिंदु है जिसकी मैं गो में जेनरिक के व्यावहारिक कार्यान्वयन की कल्पना नहीं कर सकता। समस्या के प्रत्येक पक्ष को इंटरफेस के रूप में पूरी तरह से वर्णित किया जा सकता है। लेकिन इन दोनों को एक प्रभावी संकेतन में कैसे जोड़ा जाए?

@ dc0d एल्गोरिदम को इंटरफेस की आवश्यकता होती है, डेटा-संरचनाएं उन्हें प्रदान करती हैं। यह पूर्ण व्यापकता के लिए पर्याप्त है, बशर्ते कि इंटरफेस पर्याप्त रूप से शक्तिशाली हों। इंटरफेस प्रकारों द्वारा पैरामीटर किए जाते हैं, लेकिन आपको टाइप-वेरिएबल की आवश्यकता होती है।

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

सॉर्ट को परिभाषित करने का प्रयास करते हुए, हम कुछ इस तरह चाहते हैं:

bubble_sort : forall T U I => T U -> T U requires
   ForwardIterator<T>, Readable<T>, Writable<T>,
   Ord<U>,  ValueType(T) == U, Distance type(T) == I

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

@ कीन
शायद मैं आपको गलत समझ रहा हूं, लेकिन मुझे नहीं लगता कि आप एल्गोरिदम को केवल इंटरफेस तक ही सीमित कर सकते हैं, कम से कम जिस तरह से इंटरफेस को अभी परिभाषित किया गया है।
सॉर्ट पर विचार करें।

@urandom आप एल्गोरिदम को संग्रह नहीं करते हैं। तो आप पूछते हैं, "सॉर्ट" एल्गोरिदम में कौन से डेटा एक्सेस पैटर्न मौजूद हैं, और फिर उनको वर्गीकृत करें। इसलिए इससे कोई फर्क नहीं पड़ता कि कंटेनर एक "स्लाइस" है या नहीं, हम उन सभी कार्यों को परिभाषित करने का प्रयास नहीं कर रहे हैं जिन्हें आप एक स्लाइस पर करना चाहते हैं, हम एक एल्गोरिथ्म की आवश्यकताओं को निर्धारित करने और एक इंटरफ़ेस को परिभाषित करने के लिए इसका उपयोग करने का प्रयास कर रहे हैं। एक टुकड़ा विशेष नहीं है यह सिर्फ एक प्रकार टी है जिसे हम संचालन के एक सेट को परिभाषित कर सकते हैं।

तो इंटरफेस एल्गोरिदम के पुस्तकालयों से संबंधित हैं, और आप उन एल्गोरिदम का उपयोग करने में सक्षम होने के लिए अपने स्वयं के डेटा संरचनाओं के लिए अपने स्वयं के इंटरफेस को परिभाषित कर सकते हैं। पुस्तकालय अंतर्निर्मित प्रकारों के लिए पूर्व-निर्धारित इंटरफेस के साथ आ सकते हैं।

@ कीन
मैंने सोचा कि आपका यही मतलब था। लेकिन गो के संदर्भ में, इसका शायद मतलब यह होगा कि इंटरफेस को परिभाषित करने के लिए एक महत्वपूर्ण ओवरहाल की आवश्यकता होगी। मुझे लगता है कि विभिन्न बिल्टिन ऑपरेशंस, जैसे पुनरावृत्तियों, या ऑपरेटरों को sort.Slice या math.Max जैसी चीजों के लिए इंटरफेस पर सामान्य बनाने के लिए विधियों के माध्यम से उजागर करने की आवश्यकता होगी।

तो आपको निम्न इंटरफ़ेस (छद्म कोड) के लिए समर्थन प्राप्त करना होगा:

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

और तब सभी स्लाइस में ये तरीके होंगे?

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

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

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

रैंडम एक्सेस इटरेटर के लिए, हम कुछ इस तरह समाप्त करेंगे:

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

तो एक पुनरावर्तक/समन्वय एक संग्रह के संदर्भ का एक अमूर्त है, संग्रह ही नहीं। यदि आप इटरेटर को निर्देशांक के रूप में और संग्रह को मानचित्र के रूप में सोचते हैं, तो नाम 'निर्देशांक' इसे काफी अच्छी तरह से व्यक्त करता है।

क्या हम फंक्शन क्लोजर और अनाम फंक्शन का लाभ न उठाकर गो शॉर्ट को नहीं बेच रहे हैं? गो में प्रथम श्रेणी प्रकार के रूप में कार्य/विधियां होने से सहायता मिल सकती है। उदाहरण के लिए, एल्ब्रो/फो से सिंटैक्स का उपयोग करके, बबल सॉर्ट इस तरह दिख सकता है:

type SortableContainer[C,T] struct {
    Less func(C,T,T) bool
    Swap func(C,int,int)
    Next func(C) (T,bool)
}

func (bs *SortableContainer[C,T]) BubbleSort(container C, e1,e2 T) {    
    swapCount := 1
    var item1, item2 T
    item1, ok1 = bs.Next()
    if !ok1 {return}
    item2, ok2 = bs.Next()
    if !ok2 {return}
    for swapCount > 0 {
        swapCount = 0
        for {
            if Less(item2, item1) { 
                bs.Swap(C,item2,item1)
                swapCount += 1
            }
        }
    }
}

कृपया किसी भी गलती को नज़रअंदाज करें... पूरी तरह से परीक्षित नहीं!

@mandolyte मुझे यकीन नहीं है कि यह मुझे संबोधित किया गया था? मैं वास्तव में जो सुझाव दे रहा था और आपके उदाहरण के बीच कोई अंतर नहीं देखता, सिवाय इसके कि आप बहु-पैरामीटर इंटरफेस का उपयोग कर रहे हैं, और मैं सार/संबद्ध प्रकारों का उपयोग करके उदाहरण दे रहा था। स्पष्ट होने के लिए मुझे लगता है कि आपको पूर्ण व्यापकता के लिए बहु-पैरामीटर इंटरफेस, और सार/संबद्ध प्रकार दोनों की आवश्यकता है, जिनमें से कोई भी वर्तमान में गो द्वारा समर्थित नहीं है।

मैं सुझाव दूंगा कि आपके इंटरफेस मेरे द्वारा प्रस्तावित की तुलना में कम सामान्य हैं, क्योंकि वे एक ही इंटरफेस में सॉर्ट-ऑर्डर, एक्सेस-पैटर्न और एक्सेसिबिलिटी को जोड़ते हैं, जिसके परिणामस्वरूप इंटरफेस का प्रसार होगा, उदाहरण के लिए दो ऑर्डर (कम) , अधिक), तीन एक्सेस प्रकार (रीड-ओनली, राइट-ओनली, म्यूटेबल) और पांच एक्सेस पैटर्न (फॉरवर्ड-सिंगल-पास, फॉरवर्ड-मल्टी-पास, द्विदिश, अनुक्रमित, रैंडम) केवल 11 की तुलना में 36 इंटरफेस का नेतृत्व करेंगे। अगर चिंताओं को अलग रखा जाता है।

आप इस तरह के सार प्रकारों के बजाय बहु-पैरामीटर इंटरफेस के साथ प्रस्तावित इंटरफेस को परिभाषित कर सकते हैं:

type I ForwardIterator interface {
   successor(x I) I
}
type R V Readable interface {
   source(x R) V
}
type V Ord interface {
   less(x V, y V) : bool
}

ध्यान दें कि केवल एक जिसे दो प्रकार के मापदंडों की आवश्यकता होती है, वह है पठनीय इंटरफ़ेस। हालाँकि, हम एक इटरेटर ऑब्जेक्ट के लिए उस प्रकार की वस्तुओं को 'समाहित' करने की क्षमता खो देते हैं, जो एक बड़ी समस्या है, क्योंकि अब हमें 'वैल्यू' टाइप को टाइप सिस्टम में इधर-उधर करना होगा, और हमें इसे सही करना होगा . इससे प्रकार के मापदंडों का प्रसार होता है जो अच्छा नहीं है, और इससे कोडिंग त्रुटियों की संभावना बढ़ जाती है। हम इटरेटर पर 'डिस्टेंस टाइप' को परिभाषित करने की क्षमता भी खो देते हैं, जो कि संग्रह में तत्वों को गिनने के लिए आवश्यक सबसे छोटी संख्या प्रकार है, जो आपको आवश्यक प्रकार देने के लिए int8, int16, int32 आदि में मैपिंग के लिए उपयोगी है। अतिप्रवाह के बिना तत्वों की गणना करें।

यह 'कार्यात्मक-निर्भरता' की अवधारणा से निकटता से जुड़ा हुआ है। यदि एक प्रकार दूसरे प्रकार पर कार्यात्मक रूप से निर्भर है, तो यह एक सार/संबद्ध प्रकार होना चाहिए। केवल दो प्रकार स्वतंत्र होने पर ही वे अलग-अलग प्रकार के पैरामीटर होने चाहिए।

कुछ समस्याएं:

1. बहु-पैरामीटर इंटरफेस के लिए वर्तमान f(x I) सिंटैक्स का उपयोग नहीं कर सकता। मुझे यह पसंद नहीं है कि यह वाक्यविन्यास वैसे भी इंटरफेस (जो प्रकारों पर बाधाएं हैं) को भ्रमित करता है।
2. पैरामीटरयुक्त प्रकार घोषित करने के लिए एक तरीके की आवश्यकता होगी।
3. किसी दिए गए प्रकार के पैरामीटर के साथ इंटरफेस के लिए संबंधित प्रकारों को घोषित करने का एक तरीका होना चाहिए।

@keean यकीन नहीं है कि मैं समझता हूं कि इंटरफेस की गिनती इतनी अधिक कैसे या क्यों हो जाती है। यहां एक पूर्ण कामकाजी उदाहरण दिया गया है: https://play.folang.org/p/BZa6BdsfBgZ (स्लाइस आधारित, सामान्य कंटेनर नहीं, इस प्रकार कोई अगला() विधि की आवश्यकता नहीं है)।

यह केवल एक प्रकार की संरचना का उपयोग करता है, कोई इंटरफेस नहीं। मुझे सभी अज्ञात कार्यों और बंदियों की आपूर्ति करनी है (शायद यही वह जगह है जहां व्यापार बंद है?) उदाहरण समान बबल सॉर्ट एल्गोरिथ्म का उपयोग पूर्णांकों के एक स्लाइस और "(x, y)" बिंदुओं के एक स्लाइस दोनों को सॉर्ट करने के लिए करता है, जहां मूल से दूरी कम () फ़ंक्शन का आधार है।

किसी भी दर पर, मैं यह दिखाने की उम्मीद कर रहा था कि टाइप सिस्टम में कार्य करने से कैसे मदद मिल सकती है।

@mandolyte मुझे लगता है कि आप जो प्रस्ताव दे रहे थे उसे मैंने गलत समझा। मैं देख रहा हूं कि आप किस बारे में बात कर रहे हैं "फोलैंग" जिसमें पहले से ही गो में कुछ अच्छी कार्यात्मक प्रोग्रामिंग सुविधाएं शामिल हैं। आपने जो लागू किया है वह मूल रूप से हाथ से एक बहु-पैरामीटर प्रकार-वर्ग को नलसाजी कर रहा है। आप सॉर्ट फ़ंक्शन के लिए फ़ंक्शन डिक्शनरी के रूप में जाने जाने वाले पास कर रहे हैं। यह स्पष्ट रूप से वही कर रहा है जो एक इंटरफ़ेस परोक्ष रूप से करेगा। बहु-पैरामीटर इंटरफेस और संबंधित प्रकारों से पहले इस तरह की सुविधाओं की शायद आवश्यकता होती है, लेकिन अंततः आप उन सभी शब्दकोशों को पार करने में समस्याओं में भाग लेते हैं। मुझे लगता है कि इंटरफेस क्लीनर को अधिक पठनीय कोड प्रदान करते हैं।

एक स्लाइस को सॉर्ट करना एक हल की गई समस्या है। यहाँ एक स्लाइस Quicksort.go के लिए कोड दिया गया है जिसे गो-ली (गोलंग इम्प्रूव्ड) भाषा का उपयोग करके कार्यान्वित किया गया है।

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

आप इसके साथ खेल के मैदान पर प्रयोग कर सकते हैं

पूरा उदाहरण आप खेल के मैदान में चिपका सकते हैं , क्योंकि खेल के मैदान पर Quicksort पैकेज आयात करना काम नहीं करता है।

@ गो-ली मुझे यकीन है कि आप एक टुकड़ा सॉर्ट कर सकते हैं, अगर आप नहीं कर सकते तो यह थोड़ा खराब होगा। बिंदु आम तौर पर आप एक ही कोड के साथ किसी भी रैखिक कंटेनर को सॉर्ट करने में सक्षम होना चाहते हैं, ताकि आपको केवल एक बार एक सॉर्ट एल्गोरिदम लिखना पड़े, इससे कोई फर्क नहीं पड़ता कि आप किस कंटेनर (डेटा-स्ट्रक्चर) को सॉर्ट कर रहे हैं और इससे कोई फर्क नहीं पड़ता सामग्री है।

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

@ कीन
हमारी पिछली चर्चा से संबंधित अन्य प्रश्न। मैं यह नहीं समझ सकता कि कोई मैपिंग फ़ंक्शन को परिभाषित करने में सक्षम होगा जो एक पुनरावर्तनीय से आइटम बदलता है, एक नया ठोस पुनरावर्तनीय प्रकार लौटाता है जिसका आइटम मूल से भिन्न प्रकार का हो सकता है।

और मुझे लगता है कि इस तरह के एक फ़ंक्शन का उपयोगकर्ता एक ठोस प्रकार लौटाएगा, न कि कोई अन्य इंटरफ़ेस।

@urandom यह मानते हुए कि हमारा मतलब इसे 'इन-प्लेस' करना नहीं है जो असुरक्षित होगा, आप जो चाहते हैं वह एक मैप फंक्शन है जिसमें एक प्रकार का 'रीड-इटरेटर' और दूसरे प्रकार का 'राइट-इटरेटर' होता है, जिसे कुछ इस तरह परिभाषित किया जा सकता है:

map<I, O, U>(first I, last I, out O, fn U) requires
   ForwardIterator<I>, Readable<I>,
   ForwardIterator<O>, Writable<O>,
   UnaryFunction<U>, Domain(U) == ValueType(I), Codomain(U) == ValueType(O)

स्पष्टता के लिए, "ValueType" एक संबद्ध प्रकार का इंटरफ़ेस है "पठनीय" और "लिखने योग्य", "डोमेन" और "कोडोमेन" "UnaryFunction" इंटरफ़ेस के संबद्ध प्रकार हैं। यह स्पष्ट रूप से बहुत मदद करता है यदि संकलक स्वचालित रूप से "UnaryFunction" जैसे डेटा-प्रकारों के लिए इंटरफेस प्राप्त कर सकता है। जबकि इस प्रकार का प्रतिबिंब जैसा दिखता है, ऐसा नहीं है, और यह सब स्थिर प्रकारों का उपयोग करके संकलन समय पर होता है।

@keean वर्तमान गो के इंटरफेस के संदर्भ में उन पठनीय और लिखने योग्य बाधाओं को कैसे मॉडल करें?

मेरा मतलब है, जब हमारे पास A टाइप होता है और हम B टाइप में कनवर्ट करना चाहते हैं, तो उस UnaryFunction का हस्ताक्षर func (input A) B (दाएं?) होगा, लेकिन यह कैसे हो सकता है केवल इंटरफेस का उपयोग करके मॉडलिंग की जानी चाहिए और कैसे सामान्य map (या filter , reduce , आदि) को प्रकार की पाइपलाइन रखने के लिए मॉडलिंग किया जाएगा?

@ geovanisouza92 मुझे लगता है कि "प्रकार परिवार" अच्छी तरह से काम करेंगे क्योंकि उन्हें टाइप सिस्टम में ऑर्थोगोनल तंत्र के रूप में कार्यान्वित किया जा सकता है, और फिर हास्केल में किए गए इंटरफेस के लिए वाक्यविन्यास में एकीकृत किया जा सकता है।

टाइप-फ़ैमिली प्रकार (मैपिंग) पर प्रतिबंधित फ़ंक्शन की तरह है। चूंकि इंटरफ़ेस कार्यान्वयन प्रकार द्वारा चुने जाते हैं, इसलिए हम प्रत्येक कार्यान्वयन के लिए टाइप-मैपिंग प्रदान कर सकते हैं।

तो अगर हम परिभाषित करते हैं:

ValueType MyIntArrayIterator -> Int

फ़ंक्शंस थोड़े पेचीदा होते हैं लेकिन फ़ंक्शन का एक प्रकार होता है, उदाहरण के लिए:

fn(x : Int) Float

हम इस प्रकार लिखेंगे:

Int -> Float

यह महसूस करना महत्वपूर्ण है कि -> सिर्फ एक इंफिक्स टाइप कंस्ट्रक्टर है, जैसे '[]' एक ऐरे के लिए एक टाइप कंस्ट्रक्टर है, हम इसे आसानी से लिख सकते हैं;

Fn Int Float
Or
Fn<Int, Float>

टाइप सिंटैक्स के लिए हमारी वरीयता के आधार पर। अब हम स्पष्ट रूप से देख सकते हैं कि हम कैसे परिभाषित कर सकते हैं:

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

अब जबकि हम इन सभी परिभाषाओं को हाथ से प्रदान कर सकते हैं, उन्हें आसानी से संकलक द्वारा प्राप्त किया जा सकता है।

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

धन्यवाद, @कीन।

यह अंतर्निहित/पूर्वनिर्धारित कार्यों के लिए ठीक काम करेगा। क्या आप कह रहे हैं कि एक ही अवधारणा उपयोगकर्ता द्वारा परिभाषित कार्यों या उपयोगकर्ता भूमि libs के लिए लागू की जाएगी?

कुछ त्रुटि संदर्भ के मामले में, उन "प्रकार परिवार" को रनटाइम के लिए ले जाया जाएगा?

खाली इंटरफेस, टाइप स्विच और प्रतिबिंब के बारे में कैसे?

संपादित करें: मैं सिर्फ उत्सुक हूं, शिकायत नहीं कर रहा हूं।

@ giovanisouza92 अच्छी तरह से किसी ने प्रतिबद्ध नहीं किया है कि जेनेरिक होने के लिए मुझे संदेह है। मेरा दृष्टिकोण यह है कि यदि आप जेनरिक करने जा रहे हैं तो आपको उन्हें सही करना चाहिए।

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

f(x I, y I) requires ForwardIterator<I>

बनाम

f(x ForwardIterator, y ForwardIterator)

ध्यान दें कि बाद वाले 'x' में अंतर है और 'y' विभिन्न प्रकार के हो सकते हैं जो ForwardIterator इंटरफ़ेस को संतुष्ट करते हैं, जबकि पूर्व सिंटैक्स में 'x' और 'y' दोनों एक ही प्रकार के होने चाहिए (जो फॉरवर्ड इटरेटर को संतुष्ट करता है)। यह महत्वपूर्ण है ताकि कार्य कम विवश न हों, और संकलन के दौरान ठोस प्रकारों को और अधिक प्रचारित करने की अनुमति देता है।

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

गो, रनटाइम पॉलीमॉर्फिज्म और टाइप परिवारों के बारे में सोचते हुए, हम शायद टाइप-फ़ैमिली को एक इंटरफ़ेस में सीमित करना चाहते हैं ताकि प्रत्येक संबद्ध प्रकार को रनटाइम पर एक खाली इंटरफ़ेस के रूप में माना जा सके जो धीमा होगा।

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

@ कीन
बहस को आगे बढ़ाने के लिए मुझे गलत धारणा को स्पष्ट करने दें जो मुझे लगता है कि यहां आविष्कार नहीं किया गया सिंड्रोम चल रहा है।

द्विदिश पुनरावर्तक (टी सिंटैक्स में func (*T) *[2]*T ) का प्रकार func (*) *[2]* गो-ली सिंटैक्स में है। शब्दों में यह किसी प्रकार के लिए एक सूचक लेता है और एक ही प्रकार के अगले और पिछले तत्व के लिए दो बिंदुओं पर सूचक देता है। यह मूलभूत ठोस आधारभूत प्रकार है जिसका उपयोग दोहरी लिंक की गई सूची द्वारा किया जाता है।

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

func Foreach(link func(*) *[2]*, list **, direction byte, f func(*)) {

    if nil == *list {
        return
    }

    var end *
    end = *list

    var e *
    e = (*link(*list))[direction]
    f(end)

    for (e != end) && ((*link(e))[direction] != nil) {
        var newe = (*link(e))[direction]
        f(e)
        e = newe
    }
    return
}

Foreach का उपयोग दो तरह से किया जा सकता है, आप इसे लैम्ब्डा के साथ फॉर-लूप-जैसे-पुनरावृत्ति ओवर लिस्ट या संग्रह तत्वों में उपयोग करते हैं।

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

या आप प्रत्येक संग्रह तत्व के लिए फ़ंक्शन को कार्यात्मक रूप से मैप करने के लिए इसका उपयोग कर सकते हैं।

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

निश्चित रूप से गो 1 में इंटरफेस का उपयोग करके द्विदिश इटरेटर को भी मॉडलिंग किया जा सकता है।
interface Iterator { Iter() [2]Iterator } अंतर्निहित प्रकार ("बॉक्स") को लपेटने के लिए आपको इंटरफेस का उपयोग करके इसे मॉडल करने की आवश्यकता है। इटरेटर उपयोगकर्ता तब टाइप करता है जब वह ज्ञात प्रकार का पता लगाता है और एक विशिष्ट संग्रह तत्व पर जाना चाहता है। यह संभावित रूप से संकलन समय असुरक्षित है।

आप आगे जो वर्णन कर रहे हैं वह विरासत दृष्टिकोण और जेनेरिक आधारित दृष्टिकोण के बीच का अंतर है।

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

यह दृष्टिकोण समय प्रकार की जाँच करता है कि दो संग्रहों में एक ही अंतर्निहित प्रकार है, दूसरे शब्दों में कि क्या इटरेटर वास्तव में एक ही ठोस प्रकार लौटाते हैं

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

ऊपर जैसा ही है लेकिन परिचित टी का उपयोग करने का अर्थ है प्लेसहोल्डर सिंटैक्स टाइप करें

func legacy(x Iterator, y Iterator){}

इस मामले में उपयोगकर्ता उदाहरण के लिए पूर्णांक लिंक्ड सूची को x के रूप में और फ्लोट लिंक्ड सूची को y के रूप में पास कर सकता है। इससे संभावित रन-टाइम त्रुटियां, घबराहट या अन्य आंतरिक विसंगतियां हो सकती हैं लेकिन यह सब इस बात पर निर्भर करता है कि विरासत दो पुनरावृत्तियों के साथ क्या करेगी।

अब भ्रांति है। आप दावा करते हैं कि इटरेटर्स करना और उन इटरेटर्स को सॉर्ट करने के लिए सामान्य प्रकार करना ही जाने का तरीका होगा। ऐसा करना वास्तव में एक घटिया बात होगी, यहाँ पर क्यों

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

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

एक अन्य उपाय यह है कि इटरेटर पर ओ (एन) टाइम लूप में जल्दी से, तत्वों को पॉइंटर्स को जेनेरिक पॉइंटर्स के एक स्लाइस में इकट्ठा किया जाए, जिसे []*T दर्शाया गया हो और खराब स्लाइस सॉर्ट का उपयोग करके उन जेनेरिक पॉइंटर्स को सॉर्ट करें।

कृपया अन्य लोगों के विचारों को एक मौका दें

@ गो-ली अगर हम गैर-आविष्कार-यहां सिंड्रोम से बचना चाहते हैं तो हमें परिभाषा के लिए एलेक्स स्टेपानोव को देखना चाहिए, क्योंकि उन्होंने बहुत अधिक सामान्य प्रोग्रामिंग का आविष्कार किया था। स्टेपानोव के "एलिमेंट्स ऑफ प्रोग्रामिंग" पेज 111 से लिया गया, यहां बताया गया है कि मैं इसे कैसे परिभाषित करूंगा:

Bidirectional iterator<T> =
    ForwardIterator<T>
/\ predecessor : T -> T
/\ predecessor takes constant time
/\ (forall i in T) successor(i) is defined =>
        predecessor(successor(i)) is defined and equals i
/\ (forall i in T) predecessor(i) is defined =>
        successor(predecessor(i)) is defined and equals i

यह फॉरवर्डइटरेटर की परिभाषा पर निर्भर करता है:

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

तो अनिवार्य रूप से हमारे पास एक इंटरफ़ेस है जो successor फ़ंक्शन और predecessor फ़ंक्शन के साथ-साथ कुछ स्वयंसिद्धों की घोषणा करता है जिनका उन्हें मान्य होने के लिए पालन करना चाहिए।

legacy के संबंध में ऐसा नहीं है कि विरासत गलत हो जाएगी, यह स्पष्ट रूप से वर्तमान में गो में गलत नहीं होता है, लेकिन संकलक अनुकूलन के अवसरों को याद कर रहा है, और टाइप सिस्टम ठोस प्रकारों को आगे फैलाने का अवसर खो रहा है। यह प्रोग्रामर्स को अपने इरादे को सटीक रूप से निर्दिष्ट करने के लिए भी सीमित कर रहा है। एक उदाहरण एक पहचान कार्य होगा, जिसका अर्थ है कि जिस प्रकार से इसे पारित किया गया है उसे वापस करना है:

id(x T) T

शायद यह एक पैरामीट्रिक प्रकार और एक सार्वभौमिक रूप से परिमाणित प्रकार के बीच अंतर का उल्लेख करने योग्य भी है। एक पैरामीट्रिक प्रकार id<T>(x T) T होगा जबकि सार्वभौमिक रूप से परिमाणित एक id(x T) T है (हम आम तौर पर इस मामले में सबसे बाहरी सार्वभौमिक क्वांटिफायर को छोड़ देते हैं forall T )। पैरामीट्रिक प्रकारों के साथ टाइप सिस्टम में id के लिए कॉलसाइट पर प्रदान किए गए टी के लिए एक प्रकार होना चाहिए, सार्वभौमिक परिमाणीकरण के साथ जो तब तक आवश्यक नहीं है जब तक संकलन समाप्त होने से पहले टी एक ठोस प्रकार के साथ एकीकृत हो जाता है। यह समझने का एक और तरीका है कि पैरामीट्रिक फ़ंक्शन एक प्रकार नहीं है बल्कि एक प्रकार के लिए एक टेम्पलेट है, और यह केवल एक वैध प्रकार है जब टी को एक ठोस प्रकार के लिए प्रतिस्थापित किया गया है। सार्वभौमिक रूप से परिमाणित फ़ंक्शन के साथ id में वास्तव में एक प्रकार है forall T . T -> T जिसे कंपाइलर द्वारा Int की तरह पास किया जा सकता है।

@go-li

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

डेटा संरचनाओं का आदेश देने का मतलब यह नहीं है कि आपको कभी भी डेटा को सॉर्ट करने की आवश्यकता नहीं है।

यदि हम गैर-आविष्कार-यहां सिंड्रोम से बचना चाहते हैं तो हमें परिभाषा के लिए एलेक्स स्टेपानोव को देखना चाहिए, क्योंकि उन्होंने बहुत अधिक सामान्य प्रोग्रामिंग का आविष्कार किया था।

मैं किसी भी दावे का विरोध करूंगा कि जेनेरिक प्रोग्रामिंग का आविष्कार सी ++ द्वारा किया गया था। लिस्कोव एट अल पढ़ें। 1977 CACM पेपर यदि आप जेनेरिक प्रोग्रामिंग का एक प्रारंभिक मॉडल देखना चाहते हैं जो वास्तव में काम करता है (टाइप-सेफ, मॉड्यूलर, नो कोड ब्लोट): https://dl.acm.org/citation.cfm?id=359789 (धारा 4 देखें) )

मुझे लगता है कि हमें इस चर्चा को रोक देना चाहिए और कुछ ब्लॉग पोस्ट के साथ गोलंग टीम (रूस) के आने का इंतजार करना चाहिए और फिर एक समाधान लागू करना चाहिए (vgo देखें) वे बस इसे करेंगे

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

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

यह धागा दिखाता है कि कैसे कोर टीम समुदाय के साथ समाधान खोजने में सक्रिय रूप से भाग लेने में रूचि नहीं रखती है।

लेकिन अंत में, अगर वे फिर से खुद से समाधान कर सकते हैं, तो मेरे द्वारा ठीक है, बस इसे कर लें 👍

@andrewcmyers खैर शायद "आविष्कार" थोड़ा खिंचाव था, जो शायद 1 9 71 में डेविड मुसर की तरह है, जिन्होंने बाद में एडा के लिए कुछ सामान्य पुस्तकालयों पर स्टेपानोव के साथ काम किया।

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

यह समस्या पहले से ही GitHub स्केलेबिलिटी की सीमा के तहत तनावपूर्ण है। कृपया यहां चर्चा को गो प्रस्तावों के लिए ठोस मुद्दों पर केंद्रित रखें।

गो के लिए C++ मार्ग का अनुसरण करना दुर्भाग्यपूर्ण होगा।

@andrewcmyers हां, मैं तहे दिल से सहमत हूं, कृपया सिंटैक्स सुझावों के लिए या चीजों को ठीक से करने के बेंचमार्क के रूप में C++ का उपयोग न करें। इसके बजाय, कृपया प्रेरणा के लिए D पर एक नज़र डालें ।

@ खानाबदोश-सॉफ्टवेयर

मुझे डी पसंद है, बहुत, लेकिन क्या गो को शक्तिशाली संकलन समय मेटा प्रोग्रामिंग सुविधाओं की आवश्यकता है जो डी प्रदान करता है?

मुझे पाषाण युग से उपजी सी ++ में भी टेम्पलेट सिंटैक्स पसंद नहीं है।

लेकिन सामान्य पैरामीट्रिक टाइप के बारे में क्या?जावा या C# में पाया जाने वाला मानक, यदि आवश्यक हो तो कोई इसे ParametricType के साथ अधिभारित भी कर सकता है

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

@ घुमंतू-सॉफ्टवेयर मैं यह सुझाव नहीं दे रहा था कि सी ++ सिंटैक्स या टेम्पलेट तंत्र जेनरिक करने का सही तरीका है। स्टेपानोव द्वारा परिभाषित "अवधारणाओं" के रूप में और अधिक प्रकार को बीजगणित के रूप में माना जाता है, जो जेनेरिक करने का सही तरीका है। यह कैसे दिख सकता है यह देखने के लिए हास्केल प्रकार-वर्ग देखें। हास्केल प्रकार की कक्षाएं सी ++ टेम्पलेट्स और अवधारणाओं के बहुत करीब हैं, यदि आप समझते हैं कि क्या हो रहा है।

तो सी ++ सिंटैक्स का पालन न करने के लिए +1 और टाइप-असुरक्षित टेम्पलेट सिस्टम को लागू न करने के लिए +1 :-)

@keean डी सिंटैक्स का कारण <,> से पूरी तरह से बचना और संदर्भ-मुक्त व्याकरण का पालन करना है। डी को प्रेरणा के रूप में उपयोग करने के लिए यह मेरी बात का हिस्सा है। <,> जेनेरिक पैरामीटर के सिंटैक्स के लिए वास्तव में एक खराब विकल्प है।

@ घुमंतू-सॉफ्टवेयर जैसा कि मैंने ऊपर बताया (अब एक छिपी हुई टिप्पणी में) आपको पैरामीट्रिक प्रकारों के लिए प्रकार के मापदंडों को निर्दिष्ट करने की आवश्यकता है, लेकिन सार्वभौमिक रूप से परिमाणित प्रकारों के लिए नहीं (इसलिए रस्ट और हास्केल के बीच का अंतर, जिस तरह से प्रकारों को संभाला जाता है वह वास्तव में अलग है टाइप सिस्टम में)। इसके अलावा सी ++ अवधारणाएं == हास्केल प्रकार-वर्ग == कम से कम एक वैचारिक स्तर पर इंटरफेस पर जाएं।

क्या D सिंटैक्स वास्तव में बेहतर है:

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

यह C++/Java/रस्ट स्टाइल से बेहतर क्यों है:

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

या स्कैला शैली:

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

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

हालाँकि, गो का वाक्य-विन्यास काफी मार्मिक है, शायद इसलिए कि यह पहले से ही इतना संक्षिप्त है। वर्गाकार कोष्ठकों या कोष्ठकों पर आधारित संभावित वाक्य रचनाएँ व्याकरण संबंधी अस्पष्टताएँ पैदा करती हैं जो कोण कोष्ठकों द्वारा प्रस्तुत किए गए वाक्यों से भी बदतर हैं। तो मेरे पूर्वाग्रहों के बावजूद, कोण ब्रैकेट वास्तव में गो के लिए सबसे अच्छा विकल्प प्रतीत होता है। (बेशक, वास्तविक कोण कोष्ठक भी हैं जो कोई अस्पष्टता नहीं पैदा करेंगे - - लेकिन उन्हें यूनिकोड वर्णों का उपयोग करने की आवश्यकता होगी)।

बेशक, टाइप पैरामीटर के लिए उपयोग किया जाने वाला सटीक सिंटैक्स शब्दार्थ को सही करने से कम महत्वपूर्ण नहीं है। उस बिंदु पर, सी ++ भाषा एक खराब मॉडल है। जेनस (पीएलडीआई 2015) और फ़मिलिया (ओओपीएसएलए 2017) में जेनरिक पर मेरे शोध समूह का काम एक और दृष्टिकोण प्रदान करता है जो टाइप कक्षाओं का विस्तार करता है और उन्हें इंटरफेस के साथ एकीकृत करता है।

@andrewcmyers मुझे लगता है कि वे दोनों पेपर दिलचस्प हैं, लेकिन मैं कहूंगा कि गो के लिए एक अच्छी दिशा नहीं है, क्योंकि जीनस ऑब्जेक्ट ओरिएंटेड है, और गो नहीं है, और फ़मिलिया सबटाइपिंग और पैरामीट्रिक पॉलीमॉर्फिज्म को एकीकृत करता है, और गो के पास न तो है। मुझे लगता है कि गो को या तो पैरामीट्रिक बहुरूपता या सार्वभौमिक परिमाणीकरण को अपनाना चाहिए, इसे उप-टाइपिंग की आवश्यकता नहीं है, और मेरी राय में इसे न रखने के लिए एक बेहतर भाषा है।

मुझे लगता है कि गो को ऐसे जेनरिक की तलाश करनी चाहिए जिन्हें ऑब्जेक्ट-ओरिएंटेशन की आवश्यकता नहीं है और उप-टाइपिंग की आवश्यकता नहीं है। गो में पहले से ही इंटरफेस हैं, जो मुझे लगता है कि जेनरिक के लिए एक अच्छा तंत्र है। यदि आप देख सकते हैं कि गो इंटरफेस == सी ++ अवधारणाएं == हास्केल प्रकार-वर्ग, मुझे ऐसा लगता है कि 'गो' के स्वाद को बनाए रखते हुए जेनेरिक जोड़ने का तरीका कई प्रकार के पैरामीटर लेने के लिए इंटरफेस का विस्तार करना होगा (मैं करूँगा इंटरफेस पर भी संबद्ध प्रकारों की तरह, लेकिन यह इसका एक अलग विस्तार हो सकता है जिससे कई प्रकार के पैरामीटर स्वीकार करने में मदद मिलती है)। यह महत्वपूर्ण परिवर्तन होगा, लेकिन इसे सक्षम करने के लिए फ़ंक्शन हस्ताक्षरों में इंटरफेस के लिए एक 'वैकल्पिक' सिंटैक्स होने की आवश्यकता होगी, ताकि आप इंटरफेस के लिए कई प्रकार के पैरामीटर प्राप्त कर सकें, जो कि पूरे कोण ब्रैकेट सिंटैक्स में आता है। .

गो इंटरफेस टाइप क्लास नहीं हैं - वे केवल टाइप हैं - लेकिन टाइप क्लास के साथ इंटरफेस को एकीकृत करना फैमिलिया करने का एक तरीका दिखाता है। जीनस और फ़मिलिया के तंत्र पूरी तरह से वस्तु-उन्मुख भाषाओं से बंधे नहीं हैं। गो इंटरफेस पहले से ही महत्वपूर्ण तरीकों से गो "ऑब्जेक्ट-ओरिएंटेड" बनाते हैं, इसलिए मुझे लगता है कि विचारों को थोड़ा सरलीकृत रूप में अनुकूलित किया जा सकता है।

@andrewcmyers

गो इंटरफेस टाइप क्लास नहीं हैं - वे केवल टाइप हैं

वे मेरे साथ टाइप का व्यवहार नहीं करते, क्योंकि वे बहुरूपता की अनुमति देते हैं। Addable [] जैसे पॉलीमॉर्फिक सरणी में ऑब्जेक्ट का अभी भी वास्तविक प्रकार (रनटाइम प्रतिबिंब द्वारा दृश्यमान) है, इसलिए वे बिल्कुल सिंगल-पैरामीटर प्रकार की कक्षाओं की तरह व्यवहार करते हैं। तथ्य यह है कि उन्हें टाइप सिग्नेचर में टाइप के स्थान पर रखा जाता है, टाइप वेरिएबल को छोड़कर केवल एक शॉर्टहैंड नोटेशन है। शब्दार्थ के साथ संकेतन को भ्रमित न करें।

f(x : Addable) == f<T>(x : T) requires Addable<T>

यह पहचान निश्चित रूप से केवल एकल पैरामीटर इंटरफेस के लिए मान्य है।

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

IMHO:

टाइप प्रतिबंधों को व्यक्त करने के लिए समर्पित डीएसएल के लिए अभी भी एक डिफ़ॉल्ट प्रकार होना बेहतर होगा। जैसे एक फ़ंक्शन f(s T fmt.Stringer) जो एक सामान्य फ़ंक्शन है जो किसी भी प्रकार को स्वीकार करता है जो fmt.Stringer इंटरफ़ेस को भी/संतुष्ट करता है।

इस तरह एक सामान्य कार्य करना संभव है जैसे:

func add(a, b T int) T int {
    return a + b
}

अब फ़ंक्शन add() किसी भी प्रकार T के साथ काम करता है जो int s + ऑपरेटर का समर्थन करता है।

@ dc0d मैं सहमत हूं कि वर्तमान गो सिंटैक्स को देखकर आकर्षक लगता है। हालांकि यह 'पूर्ण' नहीं है क्योंकि यह जेनरिक के लिए आवश्यक सभी बाधाओं का प्रतिनिधित्व नहीं कर सकता है, और इसे आगे बढ़ाने के लिए अभी भी एक धक्का होगा। इसके परिणामस्वरूप विभिन्न वाक्यविन्यासों का प्रसार होगा, जिन्हें मैं सादगी के लक्ष्य के साथ संघर्ष के रूप में देखता हूं। मेरा विचार है कि सरलता सरल नहीं है, इसे सबसे सरल होना चाहिए लेकिन फिर भी आवश्यक अभिव्यंजक शक्ति प्रदान करता है। वर्तमान में मुझे लगता है कि सामान्य अभिव्यक्ति शक्ति में गो की प्रमुख सीमा बहु-पैरामीटर इंटरफेस की कमी है। उदाहरण के लिए एक संग्रह इंटरफ़ेस को इस प्रकार परिभाषित किया जा सकता है:

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

तो यह सही समझ में आता है? हम संग्रह जैसी चीजों पर इंटरफेस लिखना चाहते हैं। तो सवाल यह है कि आप किसी फ़ंक्शन में इस इंटरफ़ेस का उपयोग कैसे करते हैं। मेरा सुझाव कुछ ऐसा होगा:

func[T, U] f(c T, e U) (Bool, T) requires Collection[T, U] {
   a := member(c, e)
   d := insert(c, e)
   return a, d
}

वाक्य-विन्यास केवल एक सुझाव है, हालाँकि, जब तक आप इन अवधारणाओं को भाषा में व्यक्त कर सकते हैं, तब तक मुझे इस बात से कोई फर्क नहीं पड़ता कि वाक्य-विन्यास क्या है।

@keean यह सटीक नहीं होगा अगर मैं कहूं कि मुझे सिंटैक्स से कोई आपत्ति नहीं है। लेकिन बिंदु प्रत्येक सामान्य पैरामीटर के लिए एक डिफ़ॉल्ट प्रकार होने पर जोर देना था। उस अर्थ में इंटरफ़ेस के लिए प्रदान किया गया उदाहरण बन जाएगा:

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

अब (T interface{}, U interface{}) भाग बाधाओं को परिभाषित करने में मदद करता है। उदाहरण के लिए यदि सदस्य fmt.Stringer को संतुष्ट करने के लिए हैं, तो परिभाषा होगी:

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@ dc0d यह फिर से इस अर्थ में प्रतिबंधात्मक होगा कि आप एक से अधिक प्रकार के पैरामीटर द्वारा विवश करना चाहते हैं, इस पर विचार करें:

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

मुझे लगता है कि मैं देखता हूं कि आप पैरामीटर प्लेसमेंट के साथ कहां से आ रहे हैं, आपके पास यह हो सकता है:

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

जैसा कि मैंने कहा, मैं वाक्य-विन्यास से बहुत अधिक प्रभावित नहीं हूँ, क्योंकि मुझे अधिकांश वाक्य-विन्यास की आदत हो सकती है। ऊपर से मैं इसे लेता हूं आप बहु-पैरामीटर इंटरफेस के लिए कोष्ठक '()' पसंद करते हैं।

@keean आइए heap.Interface इंटरफ़ेस पर विचार करें। मानक पुस्तकालय में वर्तमान परिभाषा है:

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

अब इसे एक सामान्य इंटरफ़ेस के रूप में फिर से लिखते हैं, डिफ़ॉल्ट प्रकार को नियोजित करते हुए:

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

यह गो 1.x कोड श्रृंखला में से कोई भी नहीं तोड़ता है। एक कार्यान्वयन टाइप एलियास रिबाइंडिंग के लिए मेरा प्रस्ताव होगा। लेकिन मुझे यकीन है कि बेहतर कार्यान्वयन हो सकते हैं।

डिफ़ॉल्ट प्रकार होने से हम जेनेरिक कोड लिख सकते हैं जिसका उपयोग Go 1.x स्टाइल कोड के साथ किया जा सकता है। और मानक पुस्तकालय बिना कुछ तोड़े एक सामान्य पुस्तकालय बन सकता है। यह बड़ी जीत आईएमओ है।

@ dc0d तो आप एक वृद्धिशील सुधार का सुझाव दे रहे हैं? आप जो सुझाव दे रहे हैं वह मुझे एक वृद्धिशील सुधार के रूप में ठीक लगता है, हालांकि इसमें अभी भी सीमित सामान्य अभिव्यक्ति शक्ति है। आप "संग्रह" और "आदेशित चयन" इंटरफेस को कैसे कार्यान्वित करेंगे?

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

@keean मैं requires Collection[T, U], Ord[U] भाग को नहीं समझता। वे प्रकार पैरामीटर T और U को कैसे प्रतिबंधित कर रहे हैं?

@ dc0d वे एक फंक्शन की तरह ही काम करते हैं, लेकिन हर चीज के लिए आवेदन करते हैं। तो किसी भी प्रकार के टीयू के लिए जो ऑर्डर किए गए कोलेक्शन हैं, हमें आवश्यकता है कि टीयू भी संग्रह का एक उदाहरण है और यू ऑर्ड है। तो कहीं भी हम ऑर्डर्ड कोलेक्शन का उपयोग करते हैं, हम संग्रह और ऑर्ड से उपयुक्त विधियों का उपयोग कर सकते हैं।

यदि हम न्यूनतम हैं तो इनकी आवश्यकता नहीं है, क्योंकि हम उन फ़ंक्शन प्रकारों में अतिरिक्त इंटरफेस शामिल कर सकते हैं जहां हमें उनकी आवश्यकता है, उदाहरण के लिए:

type OrderedCollection interface(T, U)
{
   first(c T) U
}

func[T] first(c T[]) T requires Collection(T[], T), Ord T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T), Collection(T[], T), Ord(T)
{...}

लेकिन यह अधिक पठनीय हो सकता है:

type OrderedCollection interface(T, U) 
   requires Collection(T, U), Ord(U)
{
   first(c T) U
}

func[T] first(c T[]) T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T)
{...}

@keean (IMO) जब तक प्रकार के मापदंडों के लिए एक अनिवार्य डिफ़ॉल्ट मान है, मुझे खुशी होती है। इस तरह गो 1.x कोड श्रृंखला के साथ पिछड़ी संगतता बनाए रखना संभव है। यही वह मुख्य बिंदु है जिसे मैंने बनाने की कोशिश की।

@ कीन

गो इंटरफेस टाइप क्लास नहीं हैं - वे केवल टाइप हैं

वे मेरे साथ टाइप का व्यवहार नहीं करते, क्योंकि वे बहुरूपता की अनुमति देते हैं।

हां, वे उपप्रकार बहुरूपता की अनुमति देते हैं। गो में इंटरफ़ेस प्रकारों के माध्यम से सबटाइपिंग है। इसमें स्पष्ट रूप से घोषित उपप्रकार पदानुक्रम नहीं है, लेकिन यह काफी हद तक ऑर्थोगोनल है। जो चीज गो को पूरी तरह से वस्तु-उन्मुख नहीं बनाती है वह है विरासत की कमी।

वैकल्पिक रूप से, आप इंटरफेस को प्रकार की कक्षाओं के अस्तित्वगत रूप से परिमाणित अनुप्रयोगों के रूप में देख सकते हैं। मुझे विश्वास है कि आपके मन में यही है। यही हमने जीनस और फ़मिलिया में किया।

@andrewcmyers

हां, वे उपप्रकार बहुरूपता की अनुमति देते हैं।

जहां तक ​​​​मुझे पता है कि अपरिवर्तनीय है, कोई कॉन्वर्सिस या कॉन्ट्रावेरिएंस नहीं है, यह दृढ़ता से बोलता है कि यह सबटाइपिंग नहीं है। पॉलिमॉर्फिक टाइप सिस्टम अपरिवर्तनीय हैं, इसलिए मेरे लिए ऐसा लगता है कि गो इस मॉडल के करीब है, और इंटरफेस को सिंगल पैरामीटर टाइप क्लास के रूप में मानते हुए गो की सादगी के अनुरूप अधिक लगता है। सहसंयोजक और विरोधाभास की कमी जेनरिक के लिए एक बड़ा लाभ है, बस भ्रम को देखें जैसे सी # जैसी भाषाओं में ऐसी चीजें पैदा होती हैं:

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

मुझे लगता है कि गो को इस तरह की जटिलता से पूरी तरह बचना चाहिए। मेरे लिए इसका मतलब है कि हम एक ही प्रकार की प्रणाली में जेनरिक और सबटाइपिंग नहीं चाहते हैं।

वैकल्पिक रूप से, आप इंटरफेस को प्रकार की कक्षाओं के अस्तित्वगत रूप से परिमाणित अनुप्रयोगों के रूप में देख सकते हैं। मुझे विश्वास है कि आपके मन में यही है। यही हमने जीनस और फ़मिलिया में किया।

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

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

यह शायद ध्यान देने योग्य है कि यह उसी तरह है जैसे "ट्रेट ऑब्जेक्ट्स" जंग में काम करते हैं।

गो पूरी तरह से अस्तित्व से बच सकता है (प्रोग्रामर को दिखाई दे रहा है), सहसंयोजक और विरोधाभास जो एक अच्छी बात है, और यह मेरी राय में जेनरिक को बहुत सरल और अधिक शक्तिशाली बना देगा।

जहां तक ​​​​मुझे पता है कि अपरिवर्तनीय है, कोई कॉन्वर्सिस या कॉन्ट्रावेरिएंस नहीं है, यह दृढ़ता से बोलता है कि यह सबटाइपिंग नहीं है।

पॉलिमॉर्फिक टाइप सिस्टम अपरिवर्तनीय हैं, इसलिए मेरे लिए यह इस मॉडल के करीब लगता है, और इंटरफेस को सिंगल पैरामीटर टाइप क्लास के रूप में मानना ​​​​गो की सादगी के अनुरूप अधिक लगता है।

क्या मैं सुझाव दे सकता हूं कि आप दोनों सही हैं? उस इंटरफेस में टाइप-क्लास के बराबर हैं, लेकिन टाइप-क्लास सबटाइपिंग का एक रूप है। मुझे अब तक मिली सबटाइपिंग की परिभाषाएं बहुत अस्पष्ट और सटीक हैं और "ए बी का एक उप प्रकार है, अगर एक को दूसरे के लिए प्रतिस्थापित किया जा सकता है"। जो, IMO, को आसानी से वर्ग प्रकार से संतुष्ट होने के लिए तर्क दिया जा सकता है ।

ध्यान दें, कि विचरण-तर्क अपने आप में वास्तव में IMO काम नहीं कर रहा है। वेरिएंस टाइप-कंस्ट्रक्टर्स की संपत्ति है, भाषा नहीं। और यह बहुत सामान्य है कि किसी भाषा में सभी टाइप-कंस्ट्रक्टर भिन्न नहीं होते हैं (उदाहरण के लिए, सबटाइपिंग वाली बहुत सी भाषाओं में परिवर्तनशील सरणियाँ होती हैं, जिन्हें टाइप-सुरक्षित होने के लिए अपरिवर्तनीय होना चाहिए)। इसलिए मैं नहीं देखता कि आप बिना वैरिएंट टाइप कंस्ट्रक्टर्स के सबटाइपिंग क्यों नहीं कर सकते।

साथ ही, मेरा मानना ​​है कि गो रिपोजिटरी पर किसी मुद्दे के लिए यह चर्चा थोड़ी व्यापक है। यह टाइप थ्योरी की पेचीदगियों पर चर्चा करने के बारे में नहीं होना चाहिए, बल्कि इसके बारे में होना चाहिए कि क्या और कैसे जेनरिक को गो में जोड़ा जाए।

@Merovius Variance सबटाइपिंग से जुड़ी एक संपत्ति है। सबटाइपिंग के बिना भाषाओं में, कोई भिन्नता नहीं है। पहली जगह में भिन्नता होने के लिए आपको उप-टाइपिंग करना होगा, जो कंस्ट्रक्टरों को टाइप करने के लिए कॉन्वर्सिस/कॉन्ट्रावेरिएंस समस्या पेश करता है। हालांकि आप सही हैं कि सबटाइपिंग वाली भाषा में, सभी टाइप-कंस्ट्रक्टर्स अपरिवर्तनीय होना संभव है।

टाइप-क्लास निश्चित रूप से सबटाइपिंग नहीं कर रहे हैं, क्योंकि टाइप-क्लास एक प्रकार नहीं है। हालाँकि, हम गो में 'इंटरफ़ेस प्रकार' को देख सकते हैं, जिसे रस्ट एक 'विशेषता वस्तु' कहते हैं, जो प्रभावी रूप से टाइप-क्लास से प्राप्त एक प्रकार है।

गो के शब्दार्थ इस समय किसी भी मॉडल के साथ फिट प्रतीत होते हैं, क्योंकि इसमें कोई भिन्नता नहीं है, और इसमें निहित 'विशेषता वस्तुएं' हैं। तो शायद गो एक टिपिंग पॉइंट पर है, जेनरिक और टाइप सिस्टम को सबटाइपिंग की तर्ज पर विकसित किया जा सकता है, विचरण को पेश किया जा सकता है और सी # में जेनरिक जैसी किसी चीज़ के साथ समाप्त किया जा सकता है। वैकल्पिक रूप से गो मल्टी-पैरामीटर इंटरफेस पेश कर सकता है, संग्रह के लिए इंटरफेस की इजाजत देता है, और यह इंटरफेस और 'इंटरफ़ेस प्रकार' के बीच तत्काल लिंक तोड़ देगा। उदाहरण के लिए यदि आपके पास है:

type (T, U) Collection interface {
    member : (c T, e U) Bool
    insert: (c T, e U) T
}

member(c int32[], e int32) Bool {...}
insert(c int32[], e int32) int32[] {...}

member(c float32[], e float32) Bool {...}
insert(c float32[], e float32) float32[] {...}

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

मुझे लगता है कि जेनरिक के लिए आपको स्पष्ट रूप से संग्रह जैसी चीजों को मॉडल करने में सक्षम होना चाहिए, इसलिए बहु-पैरामीटर इंटरफेस मेरे लिए जरूरी है। हालाँकि मुझे लगता है कि जेनरिक में कॉन्वर्सिस और कॉन्ट्रावेरिएंस के बीच की बातचीत एक अत्यधिक जटिल प्रकार की प्रणाली बनाती है, इसलिए मैं सबटाइपिंग से बचना चाहूंगा।

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

गो में सबटाइपिंग है या नहीं, कृपया निम्नलिखित कोड पर विचार करें:

package main

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = x

func main() {
    print("ok\n")
}

x से y तक का असाइनमेंट दर्शाता है कि y के प्रकार का उपयोग किया जा सकता है जहां x के प्रकार की अपेक्षा की जाती है। यह एक सबटाइपिंग संबंध है, बुद्धि के लिए: CloneableZ <: Cloneable , और S <: CloneableZ भी। यहां तक ​​​​कि अगर आप प्रकार की कक्षाओं के संदर्भ में इंटरफेस की व्याख्या करते हैं, तब भी यहां खेलने पर एक सबटाइपिंग संबंध होगा, जैसे कुछ S <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T] ।

ध्यान दें कि गो के लिए Clone S करने की अनुमति देना पूरी तरह से सुरक्षित होगा, लेकिन गो इंटरफेस के अनुरूप अनावश्यक रूप से प्रतिबंधात्मक नियमों को लागू करने के लिए होता है: वास्तव में, वही नियम जो जावा मूल रूप से लागू। सबटाइपिंग के लिए गैर-अपरिवर्तनीय प्रकार के कंस्ट्रक्टरों की आवश्यकता नहीं होती है, जैसा कि @Merovius ने देखा।

@andrewcmyers बहु-पैरामीटर इंटरफेस के साथ क्या होता है, जैसे अमूर्त संग्रह के लिए जरूरी?

इसके अलावा x से y तक के असाइनमेंट को बिना सबटाइपिंग के इंटरफ़ेस इनहेरिटेंस के प्रदर्शन के रूप में देखा जा सकता है। हास्केल में (जिसमें स्पष्ट रूप से सबटाइपिंग नहीं है) आप लिखेंगे:

class Cloneable t => CloneableZ t where...

जहां हमारे पास x एक प्रकार है जो CloneableZ लागू करता है जो परिभाषा के अनुसार Cloneable भी लागू करता है, इसलिए स्पष्ट रूप से y को सौंपा जा सकता है।

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

यदि हम सबटाइपिंग मॉडल के साथ चिपके रहते हैं, तो हमारे पास संग्रह प्रकार नहीं हो सकते हैं, यही कारण है कि सी ++ को टेम्पलेट्स पेश करना पड़ा, क्योंकि ऑब्जेक्ट-ओरिएंटेड सबटाइपिंग कंटेनरों जैसी अवधारणाओं को सामान्य रूप से परिभाषित करने के लिए पर्याप्त नहीं है। हम एब्स्ट्रैक्शन, ऑब्जेक्ट्स और सबटाइपिंग, और टेम्प्लेट/लक्षण और जेनरिक के लिए दो तंत्रों के साथ समाप्त होते हैं, और दोनों के बीच की बातचीत जटिल हो जाती है, परीक्षाओं के लिए C++, C#, और Scala को देखें। उन अन्य भाषाओं के अनुरूप, जेनरिक की शक्ति बढ़ाने के लिए सहसंयोजक और कंट्रावेरिएंट कंस्ट्रक्टरों को पेश करने के लिए कॉल जारी रहेंगे।

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

@ कीन

बहु-पैरामीटर इंटरफेस के साथ क्या होता है, जैसे सार संग्रह के लिए जरूरी?

कृपया जीनस और फ़मिलिया पर हमारे पेपर देखें, जो मल्टीपैरामीटर प्रकार की बाधाओं का समर्थन करते हैं। फ़ैमिलिया उन बाधाओं को इंटरफेस के साथ एकीकृत करता है और इंटरफेस को कई प्रकारों को बाधित करने की अनुमति देता है।

यदि हम सबटाइपिंग मॉडल से चिपके रहते हैं, तो हमारे पास संग्रह प्रकार नहीं हो सकते हैं

मुझे पूरी तरह से यकीन नहीं है कि "सबटाइपिंग मॉडल" से आपका क्या मतलब है, लेकिन यह बहुत स्पष्ट है कि जावा और सी # में संग्रह प्रकार हैं, इसलिए यह दावा मुझे ज्यादा समझ में नहीं आता है।

जहाँ हमारे पास x एक प्रकार है जो CloneableZ को लागू करता है जो परिभाषा के अनुसार Cloneable को भी लागू करता है, इसलिए स्पष्ट रूप से y को सौंपा जा सकता है।

नहीं, मेरे उदाहरण में, x एक चर है और y एक अन्य चर है। अगर मुझे पता है कि y कुछ CloneableZ प्रकार है और x कुछ Cloneable प्रकार है, तो इसका मतलब यह नहीं है कि मैं y से x तक असाइन कर सकता हूं। मेरा उदाहरण यही कर रहा है।

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

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

type T struct { x int }

func (t T) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = T{}
var a [2]Cloneable = [2]Cloneable{x, y}

@andrewcmyers

मुझे पूरी तरह से यकीन नहीं है कि "सबटाइपिंग मॉडल" से आपका क्या मतलब है, लेकिन यह बहुत स्पष्ट है कि जावा और सी # में संग्रह प्रकार हैं, इसलिए यह दावा मुझे ज्यादा समझ में नहीं आता है।

इस पर एक नज़र डालें कि C++ ने टेम्प्लेट क्यों विकसित किए, OO सबटाइपिंग मॉडल संग्रह जैसी चीजों को सामान्य बनाने के लिए आवश्यक सामान्य अवधारणाओं को व्यक्त करने में सक्षम नहीं था। सी # और जावा को ऑब्जेक्ट्स, सबटाइपिंग और इनहेरिटेंस से अलग एक पूर्ण जेनरिक सिस्टम भी पेश करना पड़ा, और फिर कॉन्वेंट और कॉन्ट्रावेरिएंट टाइप कंस्ट्रक्टर जैसी चीजों के साथ दो सिस्टमों के जटिल इंटरैक्शन की गड़बड़ी को साफ करना पड़ा। पश्चदृष्टि के लाभ से हम OO सबटाइपिंग से बच सकते हैं, और इसके बजाय देखें कि क्या होता है यदि हम एक साधारण टाइप की गई भाषा में इंटरफेस (टाइप-क्लास) जोड़ते हैं। यह वही है जो रस्ट ने किया है, इसलिए यह देखने लायक है, लेकिन निश्चित रूप से यह जीवन भर जटिल है। गो के पास जीसी है इसलिए इसमें वह जटिलता नहीं होगी। मेरा सुझाव है कि बहु-पैरामीटर इंटरफेस की अनुमति देने और इस जटिलता से बचने के लिए गो को बढ़ाया जा सकता है।

आपके दावे के संबंध में कि आप इस उदाहरण को हास्केल में नहीं कर सकते हैं, यहां कोड है:

{-# LANGUAGE ExistentialQuantification #-}

class ICloneable t where
    clone :: t -> t

class ICloneable t => ICloneableZ t where
    zero :: t

data S = S deriving Show

instance ICloneable S where
    clone x = x

data T = T Int deriving Show

instance ICloneable T where
    clone x = x

instance ICloneableZ T where
    zero = T 0

data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a

instance Show Cloneable where
    show (ToCloneable x) = show x

main = do
    x <- return S
    y <- return (T 27)
    a <- return [ToCloneable x, ToCloneable y]
    putStrLn (show a)

कुछ दिलचस्प अंतर, गो स्वचालित रूप से इस प्रकार data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a प्राप्त करता है क्योंकि इस तरह आप एक इंटरफ़ेस (जिसमें कोई भंडारण नहीं है) को एक प्रकार (जिसमें भंडारण है) में बदल देता है, जंग भी इन प्रकारों को प्राप्त करता है और उन्हें "विशेषता वस्तुएं" कहता है। . जावा, सी # और स्कैला जैसी अन्य भाषाओं में हम पाते हैं कि आप इंटरफेस को तत्काल नहीं कर सकते हैं, जो वास्तव में "सही" है, इंटरफेस प्रकार नहीं हैं, उनके पास कोई भंडारण नहीं है, गो स्वचालित रूप से आपके लिए एक अस्तित्व के कंटेनर का प्रकार प्राप्त कर रहा है ताकि आप इलाज कर सकें इंटरफ़ेस एक प्रकार की तरह है, और गो अस्तित्वगत कंटेनर को उसी इंटरफ़ेस के समान नाम देकर आपसे छुपाता है, जिससे इसे प्राप्त किया गया है। ध्यान देने वाली दूसरी बात यह है कि यह [2]Cloneable{x, y} सभी सदस्यों को Cloneable के लिए मजबूर करता है, जबकि हास्केल में इस तरह के निहित दबाव नहीं हैं, और हमें सदस्यों को ToCloneable के साथ स्पष्ट रूप से मजबूर करना होगा। .

मुझे यह भी बताया गया है कि हमें S और T Cloneable $ के उपप्रकारों पर विचार नहीं करना चाहिए क्योंकि S और T नहीं हैं संरचनात्मक रूप से संगत। हम सचमुच किसी भी प्रकार को क्लोनेबल का उदाहरण घोषित कर सकते हैं (केवल गो में फ़ंक्शन की प्रासंगिक परिभाषा clone घोषित करके) और उन प्रकारों का एक-दूसरे से कोई संबंध नहीं होना चाहिए।

जेनरिक के अधिकांश प्रस्तावों में अतिरिक्त टोकन शामिल हैं जो मुझे लगता है कि पठनीयता और गो की सरल भावना को नुकसान पहुंचाता है। मैं एक अलग वाक्यविन्यास का प्रस्ताव देना चाहता हूं जो मुझे लगता है कि संभवतः गो के मौजूदा व्याकरण के साथ काम कर सकता है (यहां तक ​​​​कि गीथब मार्कडाउन में सिंटैक्स हाइलाइट बहुत अच्छी तरह से होता है)।

प्रस्ताव के मुख्य बिंदु:

• गो का व्याकरण हमेशा यह निर्धारित करने का एक आसान तरीका है कि एक प्रकार की घोषणा कब समाप्त हो गई है क्योंकि कुछ विशिष्ट टोकन या कीवर्ड हैं जिन्हें हम ढूंढ रहे हैं। यदि यह सभी मामलों में सत्य है, तो टाइप तर्कों को केवल टाइप नामों के बाद ही जोड़ा जा सकता है।
• अधिकांश प्रस्तावों की तरह, समान पहचानकर्ता का अर्थ किसी भी फ़ंक्शन घोषणा में समान प्रकार है। ये पहचानकर्ता घोषणा से कभी नहीं बचते हैं।
• अधिकांश प्रस्तावों में आपको सामान्य प्रकार के तर्क घोषित करने होते हैं, लेकिन इस प्रस्ताव में यह निहित है। कुछ लोग दावा करेंगे कि यह पठनीयता या स्पष्टता को नुकसान पहुंचाता है (अंतर्निहितता खराब है), या किसी प्रकार का नाम देने की क्षमता को बाधित करता है, खंडन का पालन करें:
  
  
  
  • जब पठनीयता को नुकसान पहुंचाने की बात आती है तो मुझे लगता है कि आप इसे किसी भी तरह से बहस कर सकते हैं, अतिरिक्तया [टी] बहुत अधिक वाक्यात्मक शोर करके पठनीयता को उतना ही नुकसान पहुंचाता है।
  
  
  • जब ठीक से उपयोग किया जाता है तो अस्पष्टता किसी भाषा को कम क्रियात्मक होने में मदद कर सकती है। हम हर समय := के साथ प्रकार की घोषणाओं को हटा देते हैं क्योंकि इसके द्वारा छुपाई गई जानकारी हर बार वर्तनी के लिए पर्याप्त महत्वपूर्ण नहीं होती है।
  
  
  • एक ठोस (गैर-सामान्य) प्रकार का नामकरण करना a या t शायद खराब अभ्यास है, इसलिए यह प्रस्ताव मानता है कि इन पहचानकर्ताओं को सामान्य प्रकार के तर्कों के रूप में कार्य करने के लिए सुरक्षित रखना सुरक्षित है। हालांकि इसके लिए गो फिक्स माइग्रेशन की आवश्यकता होगी?
  
  

package main

import "fmt"

type LinkedList a struct {
  Head *Node a
  Tail *Node a
}

type Node a {
  Next *Node a
  Prev *Node a

  Value a
}

func main() {
  // Not sure about how recursive we could get with the inference
  ll := LinkedList string {
    // The string bit could be inferred
    Head: Node string { Value: "hello world" },
  }
}

func (l *LinkedList a) Append(value a) {
  newNode := &Node{Value: value}

  if l.Tail == nil {
    l.Head = newNode
    l.Tail = l.Head
    return
  }

  l.Tail.Next = newNode
  l.Tail = l.Tail.Next
}

यह एक सार से लिया गया है जिसमें थोड़ा और विवरण और साथ ही यहां प्रस्तावित योग प्रकार हैं: https://gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2

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

@ हारोंडली
मेरे लिए ठीक लग रहा है, इस सिंटैक्स का उपयोग करके हमारे पास होगा:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

@keean क्या आप कृपया Collection टाइप को थोड़ा समझाएं। मैं इसे समझने में विफल हूं:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@ dc0d संग्रह _all_ संग्रहों को सारगर्भित करने वाला एक इंटरफ़ेस है, इसलिए पेड़, सूचियाँ, स्लाइस आदि, इसलिए हमारे पास member और insert जैसे सामान्य संचालन हो सकते हैं जो किसी भी डेटा-प्रकार वाले किसी भी संग्रह पर काम करेंगे। उपरोक्त में मैंने पिछले उदाहरण में लिंक्डलिस्ट प्रकार के लिए 'इन्सर्ट' को परिभाषित करने का उदाहरण दिया है:

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

हम इसे एक स्लाइस के लिए भी परिभाषित कर सकते हैं

func insert(c []a, e a) []a {
   return append(c, e)
}

हालाँकि, हमें इसके लिए काम करने के लिए पॉलीमॉर्फिक प्रकार a के साथ @aarondl द्वारा सचित्र प्रकार के चर के साथ पैरामीट्रिक कार्यों की भी आवश्यकता नहीं है, जैसा कि आप केवल ठोस प्रकारों के लिए परिभाषित कर सकते हैं:

func insert(c *LinkedList int, e int) *LinkedList int {
   c.Append(e)
   return c
}

func insert(c *LinkedList float, e float) *LinkedList float {
   c.Append(e)
   return c
}

func insert(c int[], e int) int[] {
   return append(c, e)
}

func insert(c float[], e float) float[] {
   return append(c, e)
}

तो Collection एक कंटेनर के प्रकार और उसकी सामग्री के प्रकार दोनों पर सामान्यीकरण के लिए एक इंटरफ़ेस है, जो सामान्य कार्यों को लिखने की अनुमति देता है जो कंटेनर और सामग्री के सभी संयोजनों पर काम करते हैं।

ऐसा कोई कारण नहीं है कि आपके पास संग्रह का एक टुकड़ा भी नहीं हो सकता है []Collection जहां सामग्री सभी अलग-अलग प्रकार के संग्रह प्रकार के साथ अलग-अलग प्रकार के होंगे, प्रत्येक संयोजन के लिए member और insert परिभाषित किए गए थे। .

@aarondl यह देखते हुए कि type LinkedList a पहले से ही एक वैध प्रकार की घोषणा है, मैं इसे स्पष्ट रूप से स्पष्ट करने के लिए केवल दो तरीके देख सकता हूं: व्याकरण संदर्भ को संवेदनशील बनाना (सी, यूघ को पार्स करने की समस्याओं में शामिल होना) या असीमित लुकहेड का उपयोग करना ( विफलता के मामले में खराब त्रुटि संदेशों के कारण गो व्याकरण से बचने के लिए जाता है)। मैं कुछ गलत समझ सकता हूं, लेकिन आईएमओ जो टोकन-कम दृष्टिकोण के खिलाफ बोलता है।

गो उपयोग विधियों में @keean इंटरफेस, कार्य नहीं। आपके द्वारा सुझाए गए विशिष्ट सिंटैक्स में, ऐसा कुछ भी नहीं है जो कंपाइलर के लिए insert से *LinkedList को जोड़ता है (हास्केल में जो instance घोषणाओं के माध्यम से किया जाता है)। जिस मान पर वे काम कर रहे हैं, उसे बदलने के तरीकों के लिए भी यह सामान्य है। इनमें से कोई भी शो-स्टॉपर नहीं है, बस यह इंगित करता है कि आप जिस सिंटैक्स का सुझाव दे रहे हैं वह गो के साथ अच्छी तरह से काम नहीं करता है। शायद कुछ और पसंद है

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

जो इस संबंध में कुछ और प्रश्नों को भी प्रदर्शित करता है कि किस प्रकार के पैरामीटर को स्कोप किया जाता है और इसे कैसे पार्स किया जाना चाहिए।

@aarondl आपके प्रस्ताव के बारे में मेरे पास और भी प्रश्न हैं। उदाहरण के लिए, यह बाधाओं की अनुमति नहीं देता है, इसलिए आपको केवल अनियंत्रित बहुरूपता मिलती है। जो, सामान्य रूप से, वास्तव में उपयोगी नहीं है, क्योंकि आपको अपने द्वारा प्राप्त किए जा रहे मूल्यों के साथ कुछ भी करने की अनुमति नहीं है (उदाहरण के लिए आप मानचित्र के साथ संग्रह को लागू नहीं कर सके, क्योंकि सभी प्रकार मान्य मानचित्र कुंजी नहीं हैं)। क्या होना चाहिए जब कोई ऐसा कुछ करने की कोशिश करता है? यदि यह एक संकलन-समय त्रुटि है, तो क्या यह तात्कालिकता (सी ++ त्रुटि संदेश आगे) या परिभाषा के बारे में शिकायत करता है (आप मूल रूप से कुछ भी नहीं कर सकते, क्योंकि ऐसा कुछ भी नहीं है जो सभी प्रकार के साथ काम करता है)?

@keean फिर भी मैं यह समझने में असफल रहा कि कैसे a एक सूची (या टुकड़ा या कोई अन्य संग्रह) होने के लिए प्रतिबंधित है। क्या यह संग्रह के लिए संदर्भ-निर्भर विशेष व्याकरण है? यदि हां, तो उसका मूल्य क्या है? इस तरह से उपयोगकर्ता-परिभाषित प्रकारों को घोषित करना संभव नहीं है।

@Merovius क्या इसका मतलब है कि गो एकाधिक प्रेषण नहीं कर सकता है, और 'फ़ंक्शन' के पहले तर्क को विशेष बनाता है? इससे पता चलता है कि संबंधित प्रकार बहु-पैरामीटर इंटरफेस से बेहतर फिट होंगे। कुछ इस तरह:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt(c Collection, e Collection.Element) {...}

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

func[A] useIt(c A, e A.Element) requires A:Collection

अंतर को समझाने का प्रयास करने के लिए, बहु-पैरामीटर इंटरफेस में अतिरिक्त _input_ प्रकार होते हैं जो उदाहरण चयन में भाग लेते हैं (इसलिए एकाधिक-प्रेषण के साथ कनेक्शन), जबकि संबंधित प्रकार _output_ प्रकार हैं, केवल रिसीवर प्रकार उदाहरण चयन में भाग लेता है, और फिर संबंधित प्रकार रिसीवर के प्रकार पर निर्भर करते हैं।

@ dc0d a और b इंटरफ़ेस के प्रकार पैरामीटर हैं, जैसे हास्केल प्रकार वर्ग में। किसी चीज़ को Collection माना जाने के लिए उसे उन तरीकों को परिभाषित करना होगा जो इंटरफ़ेस के प्रकारों से मेल खाते हैं जहाँ a और b किसी भी प्रकार के हो सकते हैं। हालाँकि जैसा कि @Merovius ने बताया है, गो इंटरफेस विधि आधारित हैं, और बहु-प्रेषण का समर्थन नहीं करते हैं, इसलिए बहु-पैरामीटर इंटरफेस एक अच्छा फिट नहीं हो सकता है। गो के सिंगल-प्रेषण विधि मॉडल के साथ, फिर इंटरफेस में संबंधित प्रकार होने के बजाय, एकाधिक-पैरामीटर के बजाय बेहतर फिट प्रतीत होता है। हालांकि एकाधिक प्रेषण की कमी unify(x, y) जैसे कार्यों को लागू करना कठिन बनाती है, और आपको डबल-प्रेषण पैटर्न का उपयोग करना होगा जो बहुत अच्छा नहीं है।

मल्टी-पैरामीटर चीज़ को थोड़ा और समझाने के लिए:

type Cloneable[A] interface {
   clone(x A) A
}

यहां a किसी भी प्रकार के लिए खड़ा है, हमें परवाह नहीं है कि यह क्या है, जब तक कि सही कार्यों को परिभाषित किया जाता है, हम इसे Cloneable मानते हैं। हम इंटरफेस को स्वयं प्रकारों के बजाय प्रकारों पर बाधाओं के रूप में मानेंगे।

func clone(x int) int {...}

इसलिए 'क्लोन' के मामले में हम इंटरफ़ेस परिभाषा में int a प्रतिस्थापित करते हैं, और प्रतिस्थापन सफल होने पर हम क्लोन को कॉल कर सकते हैं। यह इस संकेतन के साथ अच्छी तरह से फिट बैठता है:

func[A] test(x A) A requires Cloneable[A] {...}

यह इसके बराबर है:

type Cloneable interface {
   clone() Cloneable
}

लेकिन एक फ़ंक्शन को एक विधि नहीं घोषित करता है, और इसे कई मापदंडों के साथ बढ़ाया जा सकता है। यदि आपके पास एकाधिक प्रेषण वाली भाषा है तो फ़ंक्शन/विधि के पहले तर्क के बारे में कुछ खास नहीं है, तो इसे किसी भिन्न स्थान पर क्यों लिखें।

चूंकि गो के पास कई प्रेषण नहीं हैं, इसलिए यह सब एक बार में बदलने के लिए बहुत अधिक लगने लगता है। ऐसा लगता है कि संबंधित प्रकार बेहतर फिट होंगे, हालांकि अधिक सीमित। यह अमूर्त संग्रह की अनुमति देगा, लेकिन एकीकरण जैसी चीजों के लिए सुरुचिपूर्ण समाधान नहीं।

@Merovius प्रस्ताव पर एक नज़र डालने के लिए धन्यवाद। आइए मैं आपकी चिंताओं को दूर करने का प्रयास करता हूं। मुझे दुख है कि आपने इस पर और चर्चा करने से पहले प्रस्ताव को अस्वीकार कर दिया, मुझे आशा है कि मैं आपका विचार बदल सकता हूं - या शायद आप मेरा बदल सकते हैं :)

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

भले ही इस प्रस्ताव के तहत type LinkedList a के साथ समस्या इतनी कठिन नहीं है क्योंकि हम जानते हैं कि a एक सामान्य प्रकार का तर्क है और इसलिए यह एक कंपाइलर त्रुटि के साथ विफल हो जाएगा जैसे type LinkedList आज विफल रहता है: prog.go:3:16: expected type, found newline (and 1 more errors) । मूल पोस्ट वास्तव में बाहर नहीं आई और इसे कहा लेकिन आपको एक ठोस प्रकार [a-z]{1} का नाम देने की अनुमति नहीं है, जिसे मैं सोचता हूं- इस समस्या को हल करता है और एक बलिदान है मुझे लगता है कि हम सब ठीक होंगे बनाना (मैं आज केवल गो कोड में एकल अक्षर नामों के साथ वास्तविक प्रकार बनाने में नुकसान देख सकता हूं)।

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

इस प्रस्ताव के तहत हमारे पास अभी भी वही समस्या होगी जैसा कि अब हम + जैसे ऑपरेटरों के साथ करते हैं ताकि आप सभी संख्यात्मक प्रकारों के लिए एक सामान्य ऐड फ़ंक्शन नहीं बना सकें, लेकिन आप एक सामान्य ऐड फ़ंक्शन को तर्क के रूप में स्वीकार कर सकते हैं। निम्न पर विचार करें:

func Sort(slice []a, compare func (a, a) bool) { ... }

स्कोपिंग के बारे में प्रश्न

आपने यहां एक उदाहरण दिया है:

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

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

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

सिंगल लेटर लोअरकेस सिंटैक्टिकल कंस्ट्रक्शन है जो उस सामान्य तर्क को बनाता है

मुझे यह अच्छा नहीं लगता; इसके लिए अलग-अलग प्रस्तुतियों की आवश्यकता होती है जो एक पहचानकर्ता संदर्भ के आधार पर होता है और इसका अर्थ यह भी है कि कुछ पहचानकर्ताओं को प्रकारों के लिए मनमाने ढंग से मना करना। लेकिन यह वास्तव में इन विवरणों के बारे में बात करने का समय नहीं है।

इस प्रस्ताव के तहत हमारे पास अभी भी वही समस्या होगी जो अब हम + . जैसे ऑपरेटरों के साथ करते हैं

मैं यह वाक्य नहीं समझता। वर्तमान में, + ऑपरेटर के पास इनमें से कोई भी समस्या नहीं है, क्योंकि इसके ऑपरेंड के प्रकार स्थानीय रूप से ज्ञात हैं और त्रुटि संदेश स्पष्ट और स्पष्ट है और समस्या के स्रोत की ओर इशारा करता है। क्या मैं यह मानने में सही हूं कि आप कह रहे हैं कि आप सामान्य मूल्यों के किसी भी उपयोग को अस्वीकार करना चाहते हैं जो सभी संभावित प्रकारों के लिए अनुमत नहीं है (मैं ऐसे कई कार्यों के बारे में नहीं सोच सकता)? और सामान्य समारोह में आपत्तिजनक अभिव्यक्ति के लिए एक संकलक त्रुटि बनाएँ? IMO जो जेनरिक के मूल्य को बहुत अधिक सीमित कर देगा।

यदि आप किसी मूल्य के साथ कुछ करना चाहते हैं तो वह मान एक इंटरफ़ेस प्रकार होना चाहिए न कि पूरी तरह से सामान्य प्रकार।

लोग जिन दो मुख्य कारणों के लिए जेनरिक चाहते हैं, वह है प्रदर्शन (इंटरफ़ेस को लपेटने से बचना) और टाइप-सेफ्टी (यह सुनिश्चित करना कि एक ही प्रकार का विभिन्न स्थानों पर उपयोग किया जाता है, जबकि इस बात की परवाह न करते हुए कि यह कौन सा है)। ऐसा लगता है कि यह उन कारणों की अनदेखी करता है।

आप एक सामान्य ऐड फ़ंक्शन को तर्क के रूप में स्वीकार कर सकते हैं।

सत्य। लेकिन काफी असंगठित। विचार करें कि sort API के बारे में कितनी शिकायतें हैं। बहुत सारे सामान्य कंटेनरों के लिए, कॉलर को लागू करने और पास करने वाले कार्यों की मात्रा निषेधात्मक प्रतीत होती है। विचार करें, इस प्रस्ताव के तहत container/heap कार्यान्वयन कैसा दिखेगा और एर्गोनॉमिक्स के संदर्भ में यह वर्तमान कार्यान्वयन से कैसे बेहतर होगा? ऐसा लगता है, जीत यहाँ नगण्य हैं, सबसे अच्छा। आपको अधिक तुच्छ कार्यों को लागू करना होगा (और प्रत्येक उपयोग साइट पर डुप्लिकेट/संदर्भ), कम नहीं।

@मेरोवियस

@aarondl . से इस बिंदु के बारे में सोच रहा हूँ

आप एक सामान्य ऐड फ़ंक्शन को तर्क के रूप में स्वीकार कर सकते हैं।

इंफिक्स ऑपरेटरों को परिभाषित करने के लिए कुछ सिंटैक्स दिए गए, अतिरिक्त ओवरलोडिंग की अनुमति देने के लिए एक Addable इंटरफ़ेस होना बेहतर होगा:

type Addable interface {
   + (x Addable, y Addable) Addable
}

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

type Addable[A] interface {
   + (x A, y A) A
}

फिर आपको बहु-प्रेषण करने के लिए गो की भी आवश्यकता होगी जिसका अर्थ यह होगा कि किसी फ़ंक्शन में सभी तर्कों को इंटरफ़ेस मिलान के लिए रिसीवर की तरह माना जाता है। तो उपरोक्त उदाहरण में कोई भी प्रकार Addable है यदि कोई फ़ंक्शन + परिभाषित है जो इंटरफ़ेस परिभाषा में फ़ंक्शन परिभाषाओं को पूरा करता है।

लेकिन उन परिवर्तनों को देखते हुए अब आप लिख सकते हैं:

type S struct {
   value: int
}

func (+) (x S, y S) S {
   return S {
      value: x.value + y.value
   }
}

func main() {
    println(S {value: 27} + S {value: 5})
}

बेशक फंक्शन ओवरलोडिंग और मल्टीपल-डिस्पैच कुछ ऐसा हो सकता है जो लोग गो में कभी नहीं चाहते हैं, लेकिन फिर उपयोगकर्ता परिभाषित प्रकारों जैसे वैक्टर, मैट्रिसेस, कॉम्प्लेक्स नंबर आदि पर बुनियादी अंकगणित को परिभाषित करने जैसी चीजें हमेशा असंभव होंगी। जैसा कि मैंने ऊपर कहा था कि इंटरफेस पर 'संबद्ध प्रकार' सामान्य प्रोग्रामिंग क्षमता में कुछ वृद्धि की अनुमति देगा, लेकिन पूर्ण व्यापकता नहीं। क्या बहु-प्रेषण (और संभावित रूप से कार्य ओवरलोडिंग) कुछ ऐसा है जो कभी भी गो में हो सकता है?

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

कुछ इस पर विचार कर सकते हैं कि एक विशेषता :) AFAIR कुछ प्रस्ताव या धागा कहीं न कहीं तैर रहा है, इस पर चर्चा कर रहा है कि क्या इसे करना चाहिए। एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि यह - फिर से - विषय से भटक रहा है। ऑपरेटर ओवरलोडिंग (या सामान्य "अधिक हास्केल कैसे बनाएं" विचार) वास्तव में इस मुद्दे का मुद्दा नहीं है :)

क्या बहु-प्रेषण (और संभावित रूप से कार्य ओवरलोडिंग) कुछ ऐसा है जो कभी भी गो में हो सकता है?

नेवर से नेवर। हालांकि, मैं व्यक्तिगत रूप से इसकी उम्मीद नहीं करता।

@मेरोवियस

कुछ लोग इसे एक विशेषता मान सकते हैं :)

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

यह देखते हुए कि फ़ंक्शन ओवरलोडिंग और एकाधिक-प्रेषण दायरे से बाहर है, और @aarondl के सुझाव के साथ पार्सिंग समस्याओं को भी दिया गया है, ऐसा लगता है कि इंटरफेस में संबंधित प्रकार जोड़ना, और कार्यों के लिए पैरामीटर टाइप करना उतना ही होगा जितना आप चाहते हैं गो में जेनरिक के साथ जाएं।

ऐसा कुछ सही प्रकार की बात प्रतीत होगी:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt<T>(c T, e T.Element) requires T:Collection {...}

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

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

सार्वभौमिक रूप से परिमाणित प्रकारों के साथ, आप useIt को एक तर्क के रूप में पारित कर सकते हैं, और फिर इसे f के अंदर एक प्रकार पैरामीटर प्रदान किया जा सकता है। पैरामीट्रिक प्रकारों का पक्ष लेने का कारण यह है कि आप बहुरूपता को संकलित समय पर मोनोमोर्फिज़ कर सकते हैं जिसका अर्थ है कि रनटाइम पर बहुरूपी कार्यों का कोई विस्तार नहीं है। मुझे यकीन नहीं है कि यह गो के साथ एक चिंता का विषय है, क्योंकि गो पहले से ही इंटरफेस पर रनटाइम डिस्पैच कर रहा है, इसलिए जब तक useIt के लिए टाइप पैरामीटर संग्रह को लागू करता है, आप रनटाइम पर सही रिसीवर को भेज सकते हैं, इसलिए सार्वभौमिक मात्रा का ठहराव शायद गो के लिए सही तरीका है।

मुझे आश्चर्य है, SFINAE का उल्लेख केवल @bcmills द्वारा किया गया है। प्रस्ताव में भी उल्लेख नहीं किया गया है (हालांकि उदाहरण के रूप में क्रमबद्ध है)।
स्लाइस और लिंक्डलिस्ट के लिए Sort कैसा दिख सकता है?

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

कभी-कभी मुझे लगता है कि जिन लोगों को जेनरिक की आवश्यकता नहीं है, उन्होंने अभी तक एक बड़ा पर्याप्त कार्यक्रम नहीं लिखा है।

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

और गलती न करें "उन्हें सही करना चाहते हैं और यह इंगित करना कि मौजूदा प्रस्ताव कहां नहीं हैं" "मूल रूप से बहुत ही विचार का विरोध" के साथ।

@aarondl के सुझाव के साथ पार्सिंग समस्याओं को भी दिया।

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

@urandom

मैं यह नहीं समझ सकता कि कोई आपके सुझाव के साथ एक सामान्य 'स्लाइस' संग्रह को कैसे परिभाषित करेगा।

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

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

हालाँकि अब आपको विशेषज्ञता से भी निपटना होगा, क्योंकि कोई अधिक विशिष्ट []int के लिए संबंधित प्रकार और विधियों को परिभाषित कर सकता है और आपको इसका उपयोग करना होगा। आम तौर पर आप अधिक विशिष्ट उदाहरण के साथ जाएंगे, लेकिन यह जटिलता की एक और परत जोड़ता है।

मुझे यकीन नहीं है कि इससे आपको वास्तव में कितना फायदा होता है। ऊपर मेरे मूल उदाहरण के साथ आप इंटरफ़ेस का उपयोग करके सामान्य संग्रह पर कार्य करने के लिए सामान्य एल्गोरिदम लिख सकते हैं, और आपको केवल उन प्रकारों के लिए विधियां और संबंधित प्रकार प्रदान करना होगा जिनका आप वास्तव में उपयोग करते हैं। मेरे लिए प्रमुख जीत एल्गोरिदम को मनमाने ढंग से संग्रह पर क्रमबद्ध करने और उन एल्गोरिदम को पुस्तकालय में रखने में सक्षम होना है। अगर मेरे पास "आकृतियों" की एक सूची है तो मुझे आकार की सूची के लिए संग्रह इंटरफ़ेस विधियों को परिभाषित करना होगा, और फिर मैं पुस्तकालय में किसी भी एल्गोरिदम का उपयोग कर सकता हूं। सभी स्लाइस प्रकारों के लिए इंटरफ़ेस विधियों को परिभाषित करने में सक्षम होने के कारण मेरे लिए कम रुचि है, और गो के लिए बहुत अधिक जटिलता हो सकती है?

@मेरोवियस

हालाँकि, मुझे वास्तव में इसकी आवश्यकता नहीं दिख रही है। मैं बड़े कोडबेस में भी बिना ठीक कर रहा हूं।

यदि आप 100,000 लाइन प्रोग्राम के साथ सामना कर सकते हैं, तो आप 100,000 गैर-जेनेरिक लाइनों (दोहराव के कारण) की तुलना में 100,000 जेनेरिक लाइनों के साथ अधिक करने में सक्षम होंगे। तो आप एक सुपर-स्टार डेवलपर हो सकते हैं जो बहुत बड़े कोडबेस से निपटने में सक्षम हैं, लेकिन आप अभी भी एक बहुत बड़े जेनेरिक कोडबेस के साथ और अधिक हासिल करेंगे क्योंकि आप अनावश्यकता को खत्म कर देंगे। वह सामान्य कार्यक्रम और भी बड़े गैर-सामान्य कार्यक्रम में विस्तारित होगा। मुझे ऐसा लगता है कि आपने अभी तक अपनी जटिलता की सीमा को पार नहीं किया है।

हालांकि मुझे लगता है कि आप सही हैं 'ज़रूरत' बहुत मजबूत है, मैं खुशी से गो कोड लिख रहा हूं, जेनेरिक की कमी के बारे में कभी-कभी निराशा के साथ, और मैं बस और कोड लिखकर इसके आसपास काम कर सकता हूं, और गो में वह कोड सीधे तौर पर प्रत्यक्ष है और शाब्दिक।

विवश बहुरूपता की कमी शब्दार्थ से कहीं अधिक गंभीर है। आईएमओ, इसके बिना जेनरिक जोड़ना वास्तव में प्रयास के लायक नहीं है।

मैं इससे सहमत हु।

आप 100,000 जेनेरिक लाइनों के साथ 100,000 गैर-जेनेरिक लाइनों की तुलना में अधिक करने में सक्षम होंगे (दोहराव के कारण)

मैं उत्सुक हूं, आपके काल्पनिक उदाहरण से, उन पंक्तियों में से कितना% एक सामान्य कार्य होगा?
मेरे अनुभव में यह 2% से कम है (115k LOC वाले कोडबेस से), इसलिए मुझे नहीं लगता कि यह एक अच्छा तर्क है जब तक कि आप "संग्रह" के लिए एक पुस्तकालय नहीं लिखते हैं

मेरी इच्छा है कि हमें अंततः जेनरिक मिलें

@ कीन

आपके दावे के संबंध में कि आप इस उदाहरण को हास्केल में नहीं कर सकते हैं, यहां कोड है:

यह कोड नैतिक रूप से मेरे द्वारा लिखे गए कोड के बराबर नहीं है। यह ICloneable इंटरफ़ेस के अलावा एक नया क्लोनेबल रैपर प्रकार पेश करता है। गो कोड को रैपर की जरूरत नहीं थी; न ही अन्य भाषाएं जो सबटाइपिंग का समर्थन करती हैं।

@andrewcmyers

यह कोड नैतिक रूप से मेरे द्वारा लिखे गए कोड के बराबर नहीं है। यह ICloneable इंटरफ़ेस के अलावा एक नया क्लोनेबल रैपर प्रकार पेश करता है।

क्या यह कोड यह नहीं करता है:

type Cloneable interface {...}

यह इंटरफ़ेस से प्राप्त डेटा-प्रकार 'क्लोनेबल' को शामिल करता है। आप 'ICloneable' नहीं देखते हैं क्योंकि आपके पास इंटरफेस के लिए इंस्टेंस घोषणाएं नहीं हैं, आप केवल विधियों की घोषणा करते हैं।

क्या आप इसे उप-टाइप करने पर विचार कर सकते हैं जब इंटरफ़ेस को लागू करने वाले प्रकारों को संरचनात्मक रूप से संगत नहीं होना चाहिए?

@keean मैं Cloneable को केवल एक प्रकार मानूंगा, वास्तव में "डेटा प्रकार" नहीं। जावा जैसी भाषा में, अनिवार्य रूप से Cloneable अमूर्तता में कोई अतिरिक्त लागत नहीं होगी, क्योंकि आपके कोड के विपरीत कोई आवरण नहीं होगा।

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

@andrewcmyers
मैं प्रकार और डेटा प्रकार का परस्पर उपयोग कर रहा हूं। कोई भी प्रकार जिसमें डेटा हो सकता है वह डेटा-प्रकार है।

क्योंकि आपके कोड के विपरीत कोई आवरण नहीं होगा।

हमेशा एक आवरण होता है क्योंकि गो प्रकार हमेशा बॉक्सिंग होते हैं, इसलिए रैपर हर चीज के आसपास मौजूद होता है। हास्केल को स्पष्ट होने के लिए रैपर की आवश्यकता है क्योंकि इसमें अनबॉक्स किए गए प्रकार हैं।

इंटरफ़ेस को लागू करने वाले प्रकारों के बीच संरचनात्मक समानता, इसलिए मैं इस बारे में उलझन में हूं कि आप यहां क्या सोच रहे हैं।

स्ट्रक्चरल सबटाइपिंग के लिए आवश्यक है कि प्रकार 'संरचनात्मक रूप से संगत' हों। चूंकि विरासत के साथ ओओ भाषा में कोई स्पष्ट प्रकार का पदानुक्रम नहीं है, उप-प्रकार नाममात्र नहीं हो सकता है, इसलिए यह संरचनात्मक होना चाहिए, अगर यह बिल्कुल भी है।

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

मुझे वास्तव में लगता है कि गो अभी दोनों मॉडलों में फिट बैठता है, और यह यहां से किसी भी तरह से जा सकता है, लेकिन मैं सुझाव दूंगा कि इसे एक इंटरफ़ेस कॉल करना एक वर्ग नहीं है जो सोचने का एक गैर-सबटाइपिंग तरीका सुझाता है।

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

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

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

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

@Merovius निरंतर संवाद के लिए धन्यवाद।

| लोग जिन दो मुख्य कारणों के लिए जेनरिक चाहते हैं, वह है प्रदर्शन (इंटरफ़ेस को लपेटने से बचना) और टाइप-सेफ्टी (यह सुनिश्चित करना कि एक ही प्रकार का विभिन्न स्थानों पर उपयोग किया जाता है, जबकि इस बात की परवाह न करते हुए कि यह कौन सा है)। ऐसा लगता है कि यह उन कारणों की अनदेखी करता है।

हो सकता है कि हम देख रहे हों कि मैंने क्या प्रस्तावित किया है, क्योंकि मेरे दृष्टिकोण से यह इन दोनों चीजों को करता है जहां तक ​​​​मैं बता सकता हूं? लिंक की गई सूची के उदाहरण में इंटरफेस के साथ कोई रैपिंग नहीं है और इसलिए इसे निष्पादक के रूप में होना चाहिए जैसे कि किसी दिए गए प्रकार के लिए हाथ से लिखा गया हो। टाइप-सुरक्षा पक्ष में यह वही है। क्या कोई प्रति-उदाहरण है जो आप यहां दे सकते हैं ताकि मुझे यह समझने में मदद मिल सके कि आप कहां से आ रहे हैं?

| सत्य। लेकिन काफी असंगठित। विचार करें कि सॉर्ट एपीआई के बारे में कितनी शिकायतें हैं। बहुत सारे सामान्य कंटेनरों के लिए, कॉलर को लागू करने और पास करने वाले कार्यों की मात्रा निषेधात्मक प्रतीत होती है। विचार करें, इस प्रस्ताव के तहत एक कंटेनर/ढेर कार्यान्वयन कैसा दिखेगा और एर्गोनॉमिक्स के संदर्भ में यह वर्तमान कार्यान्वयन से कैसे बेहतर होगा? ऐसा लगता है, जीत यहाँ नगण्य हैं, सबसे अच्छा। आपको अधिक तुच्छ कार्यों को लागू करना होगा (और प्रत्येक उपयोग साइट पर डुप्लिकेट/संदर्भ), कम नहीं।

मैं वास्तव में इससे बिल्कुल भी चिंतित नहीं हूं। मुझे विश्वास नहीं है कि कार्यों की मात्रा निषेधात्मक होगी, लेकिन मैं निश्चित रूप से कुछ प्रति-उदाहरण देखने के लिए तैयार हूं। याद रखें कि जिस एपीआई के बारे में लोगों ने शिकायत की थी, वह वह नहीं था जिसके लिए आपको एक फ़ंक्शन प्रदान करना था, बल्कि यहां मूल था: https://golang.org/pkg/sort/#Interface जहां आपको एक नया प्रकार बनाने की आवश्यकता थी जो कि बस था अपना टुकड़ा + प्रकार, और फिर उस पर 3 विधियों को लागू करें। इस इंटरफ़ेस से जुड़ी शिकायतों और दर्द के आलोक में निम्नलिखित बनाया गया था: https://golang.org/pkg/sort/#Slice , मुझे इस एपीआई से कोई समस्या नहीं है और हम इसके प्रदर्शन दंड की वसूली करेंगे प्रस्ताव के तहत हम केवल परिभाषा को func Slice(slice []a, less func(a, a) bool) में बदलकर चर्चा कर रहे हैं।

container/heap डेटा संरचना के संदर्भ में कोई फर्क नहीं पड़ता कि आप किस सामान्य प्रस्ताव को स्वीकार करते हैं जिसके लिए एक संपूर्ण पुनर्लेखन की आवश्यकता होती है। container/heap ठीक उसी तरह जैसे sort पैकेज सिर्फ आपकी खुद की डेटा संरचना के शीर्ष पर एल्गोरिदम प्रदान कर रहा है, लेकिन न तो पैकेज कभी भी डेटा संरचना का मालिक है क्योंकि अन्यथा हमारे पास []interface{} और उससे जुड़ी लागत। संभवतः हम उन्हें बदल देंगे क्योंकि आप एक Heap प्राप्त करने में सक्षम होंगे जो जेनरिक के लिए एक ठोस प्रकार के साथ एक टुकड़ा का मालिक है, और यह मेरे द्वारा देखे गए किसी भी प्रस्ताव के तहत सच है (मेरे अपने सहित) .

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

निम्नलिखित हैश तालिका परिभाषा पर विचार करें:

// Hasher turns a key into a hash
type Hasher interface {
  func Hash() []byte
}

type HashTable v struct {
   Keys   []Hasher
   Values []v
}

// Note that the generic arguments must be repeated here and immediately
// understood without reading another line of code, which to me
// is a readability win over the sudden appearance of the K and V which are
// defined elsewhere in the code in the example below. This is of course because
// the tokenized type declarations with constraints are fairly painful in general
// and repeating them everywhere is simply too much.
func (h (*HashTable v)) Insert(key Hasher, value v) { ... }

क्या हम कह रहे हैं कि []Hasher प्रदर्शन/भंडारण चिंताओं के कारण एक गैर-स्टार्टर है और गो में एक सफल जेनरिक कार्यान्वयन के लिए हमारे पास निम्नलिखित जैसा कुछ होना चाहिए?

// Without selecting another proposal I have no idea how the constraint might be defined or implemented so let's just pretend
type [K: Hasher, V] HashTable a struct {
   Keys   []K
   Values []V
}

func (h *HashTable) Insert(key K, value V) { ... }

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

हो सकता है कि हम देख रहे हों कि मैंने क्या प्रस्तावित किया है, क्योंकि मेरे दृष्टिकोण से यह इन दोनों चीजों को करता है जहां तक ​​​​मैं बता सकता हूं?

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

उदाहरण के लिए, आपके प्रस्ताव (जैसा कि मूल रूप से लिखा गया है) ने वास्तव में किसी भी प्रकार का एक सामान्य नक्शा लिखने की अनुमति नहीं दी, क्योंकि इसके लिए == (जो एक बाधा है, का उपयोग करके कम से कम कुंजियों की तुलना करने में सक्षम होना चाहिए, इसलिए एक को लागू करना मानचित्र को विवश बहुरूपता की आवश्यकता है)।

इस इंटरफ़ेस से जुड़ी शिकायतों और दर्द के आलोक में निम्नलिखित बनाया गया था: https://golang.org/pkg/sort/#Slice

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

लेकिन, फिर से, आप अपने द्वारा किए गए एक विशिष्ट बिंदु पर प्रतिक्रिया उद्धृत कर रहे हैं, अर्थात् आप एपीआई में फ़ंक्शन अक्षर पास करके बाध्य बहुरूपता प्राप्त कर सकते हैं। और उस विशिष्ट तरीके से आपने विवश बहुरूपता की कमी के आसपास काम करने का सुझाव दिया है, जिसके लिए पुराने एपीआई को कम या ज्यादा लागू करने की आवश्यकता होगी। यानी आप इस तर्क पर मेरी प्रतिक्रिया उद्धृत कर रहे हैं, जिसे आप फिर दोहरा रहे हैं:

हम जिस प्रस्ताव पर चर्चा कर रहे हैं, उसके तहत हम इसके प्रदर्शन दंड को केवल func स्लाइस (स्लाइस [] ए, कम फंक (ए, ए) बूल) में बदलकर पुनर्प्राप्त करेंगे।

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

यह मेरे द्वारा यहां देखे गए किसी भी प्रस्ताव के तहत सच है (मेरे अपने सहित)।

अधिकांश जेनेरिक प्रस्तावों में टाइप-पैरामीटर को बाधित करने का कोई तरीका शामिल है। यानी "प्रकार पैरामीटर में कम विधि होनी चाहिए" या "प्रकार पैरामीटर तुलनीय होना चाहिए" व्यक्त करने के लिए। आपका - AFAICT - नहीं।

निम्नलिखित हैश तालिका परिभाषा पर विचार करें:

आपकी परिभाषा अधूरी है। ए) कुंजी प्रकार को भी समानता की आवश्यकता होती है और बी) आप विभिन्न कुंजी प्रकारों का उपयोग करने से नहीं रोक रहे हैं। यानी यह कानूनी होगा:

type hasherA uint64

func (a hasherA) Hash() []byte {
    b := make([]byte, 8)
    binary.BigEndian.PutUint64(b, uint64(a))
    return b
}

type hasherB string

func (b hasherB) Hash() []byte {
    return []byte(b)
}

h := new(HashTable int)
h.Insert(hasherA(42), 1)
h.Insert(hasherB("Hello world"), 2)

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

type HashTable k v struct {
    Keys []k
    Values []v
}

func (h *(HashTable k v)) Insert(key k, value v) {
    // You can't actually do anything with k, as it's unconstrained. i.e. you can't hash it, compare it…
    // Implementing this is impossible in your proposal.
}

// If it weren't impossible, you'd get this:
h := new(HashTable hasherA int)
h[hasherA(42)] = 1
h[hasherB("Hello world")] = 2 // compile error - can't use hasherB as hasherA

या, अगर यह मदद करता है, तो कल्पना करें कि आप हैश-सेट को लागू करने का प्रयास कर रहे हैं। आपको वही समस्या मिलेगी लेकिन अब परिणामी कंटेनर में interface{} पर कोई अतिरिक्त टाइप-चेकिंग नहीं है।

यही कारण है कि आपका प्रस्ताव सबसे बुनियादी उपयोग-मामलों को संबोधित नहीं करता है: यह बहुरूपता को बाधित करने के लिए इंटरफेस पर निर्भर करता है, लेकिन फिर वास्तव में स्थिरता के लिए उन इंटरफेस की जांच करने का कोई तरीका प्रदान नहीं करता है। आप या तो लगातार टाइप-चेकिंग कर सकते हैं या बहुरूपता को बाधित कर सकते हैं, लेकिन दोनों नहीं। लेकिन आपको दोनों की जरूरत है।

कि गो में एक सफल जेनरिक कार्यान्वयन के लिए हमारे पास निम्नलिखित जैसा कुछ होना चाहिए?

कम से कम मैं इसके बारे में कैसा महसूस करता हूं, हाँ, बहुत ज्यादा। यदि कोई प्रस्ताव टाइप-सुरक्षित कंटेनर या सॉर्ट लिखने की अनुमति नहीं देता है या ... यह वास्तव में मौजूदा भाषा में कुछ भी नहीं जोड़ता है जो लागत को उचित ठहराने के लिए पर्याप्त है।

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

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

इसे पढ़कर यह स्पष्ट है कि आपने इस प्रस्ताव के तहत जेनेरिक स्लाइस के काम करने के तरीके को पूरी तरह से गलत समझा है। इस गलतफहमी के कारण आप इस गलत निष्कर्ष पर पहुंचे हैं कि "यह इंटरफ़ेस अभी भी आपके प्रस्ताव में संभव नहीं है"। किसी भी प्रस्ताव के तहत एक सामान्य टुकड़ा संभव होना चाहिए, मैं यही सोचता हूं। और दुनिया में len() जैसा कि मैंने देखा इसे इस प्रकार परिभाषित किया जाएगा: func len(slice []a) , जो एक सामान्य टुकड़ा तर्क है जिसका अर्थ है कि यह किसी भी टुकड़े के लिए गैर-प्रतिबिंबित तरीके से लंबाई की गणना कर सकता है। जैसा कि मैंने ऊपर कहा (आसान स्लाइस हेरफेर) इस प्रस्ताव का यह बहुत कुछ है और मुझे खेद है कि मैं अपने द्वारा दिए गए उदाहरणों और मेरे द्वारा किए गए सार के माध्यम से इसे अच्छी तरह से व्यक्त करने में सक्षम नहीं था। एक सामान्य टुकड़ा का उपयोग आसानी से []int के रूप में किया जा सकता है, मैं फिर से कहूंगा कि कोई भी प्रस्ताव जो इसे संबोधित नहीं करता है (स्लाइस/सरणी स्वैप, असाइनमेंट, लेन, कैप इत्यादि। ) मेरी राय में कम पड़ रहा है।

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

सबसे अच्छा प्रति-उदाहरण वह सॉर्ट फ़ंक्शन है जिसकी हम पहले चर्चा कर रहे थे।

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

जैसा कि आप देख सकते हैं कि ऐसा करने का कोई अच्छा तरीका नहीं है, और टोकन-स्पैम जेनरिक के दृष्टिकोण फिर से बेहतर लगने लगते हैं। इन पर बाधाओं को परिभाषित करने के लिए हमें मूल प्रस्ताव से दो चीजों को बदलने की जरूरत है:

• एक प्रकार के तर्क को इंगित करने और इसे बाधाएं देने का एक तरीका होना चाहिए।
• बाधाओं को एक परिभाषा से अधिक समय तक चलने की आवश्यकता है, शायद वह दायरा एक प्रकार है, शायद वह दायरा एक फ़ाइल है (फ़ाइल वास्तव में बहुत उचित लगती है)।

अस्वीकरण: निम्नलिखित प्रस्ताव में वास्तविक संशोधन नहीं है क्योंकि मैं सिर्फ यादृच्छिक प्रतीकों को वहां फेंक रहा हूं, मैं इन वाक्यविन्यासों का उदाहरण उदाहरण के रूप में उपयोग कर रहा हूं ताकि यह स्पष्ट किया जा सके कि प्रस्ताव में संशोधन करने के लिए हम क्या कर सकते हैं क्योंकि यह मूल रूप से खड़ा है

// Decorator style, follows the definition of the type thorugh all
// of it's methods.
<strong i="14">@a</strong>: Lesser, Hasher, Equaler
func Sort(slice []a) { ... }
<strong i="15">@k</strong>: Equaler, Hasher
type HashTable k v struct

// Inline, follows the definition of the type through
// all of it's methods.
func [a: Hasher, Equaler] Sort(slice []a) { ... }
type [k: Hasher, Equaler] HashTable k v struct

// File-scope global style, if k appears as a generic argument
// it's constrained by this that appears at the top of the file underneath
// the imports but before any other code.
<strong i="16">@k</strong>: Equaler, Hasher

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

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

func map(slice []a, mapper func(a) b) {
  for i := range slice {
    slice[i] = mapper(slice[i])
  }
}

type Result a b struct {
  Ok  a
  Err b
}

@aarondl मुझे समझाने में जाना होगा। कारण आपको प्रकार की बाधाओं की आवश्यकता है क्योंकि यही एकमात्र तरीका है जिससे आप किसी प्रकार पर फ़ंक्शन या विधियों को कॉल कर सकते हैं। अप्रतिबंधित प्रकार पर विचार करें a यह किस प्रकार का हो सकता है, ठीक है यह एक स्ट्रिंग या एक इंट या कुछ भी हो सकता है। इसलिए हम इस पर कोई फंक्शन या मेथड नहीं कह सकते क्योंकि हमें टाइप का पता नहीं है। हम प्रकार प्राप्त करने के लिए टाइप-स्विच और रनटाइम प्रतिबिंब का उपयोग कर सकते हैं, और फिर उस पर कुछ फ़ंक्शन या विधियों को कॉल कर सकते हैं, लेकिन यह कुछ ऐसा है जिसे हम जेनेरिक से बचना चाहते हैं। जब आप एक प्रकार को बाधित करते हैं उदाहरण के लिए a एक पशु है तो हम किसी जानवर के लिए परिभाषित किसी भी विधि को a पर कॉल कर सकते हैं।

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

उदाहरण के लिए क्या होगा यदि मानचित्र को कॉल करने वाला फ़ंक्शन भी सामान्य है? क्या होगा यदि वह फ़ंक्शन जो कॉल करता है जो सामान्य है आदि। हम मैपर को कैसे परिभाषित करते हैं यदि हम अभी तक a के प्रकार को नहीं जानते हैं?

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

mapper को परिभाषित करने का प्रयास करते समय हम x पर कौन से फ़ंक्शन कॉल कर सकते हैं?

@keean मैं बाधाओं के उद्देश्य और कार्य को समझता हूं। मैं बस उन्हें सामान्य कंटेनर स्ट्रक्चर (सामान्य कंटेनर नहीं बोलने के लिए) और सामान्य स्लाइस जैसी साधारण चीजों के रूप में महत्व नहीं देता और इसलिए उन्हें मूल प्रस्ताव में भी शामिल नहीं किया।

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

आपके उदाहरण के लिए, आप x पर कोई फ़ंक्शन नहीं कॉल कर सकते हैं। लेकिन आप अभी भी स्लाइस पर किसी अन्य स्लाइस की तरह काम कर सकते हैं जो अपने आप में बहुत उपयोगी है। यह भी सुनिश्चित नहीं है कि func के अंदर func क्या है ... शायद आप एक var को असाइन करना चाहते थे?

@ हारोंडली
धन्यवाद, मैंने वाक्य रचना को ठीक कर दिया है, हालांकि मुझे लगता है कि अर्थ अभी भी स्पष्ट था।

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

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

@ कीन
क्या बहु-प्रेषण यह सब आवश्यक है? बहुत कम भाषाएँ मूल रूप से इसका समर्थन करती हैं। यहां तक ​​​​कि सी ++ भी इसका समर्थन नहीं करता है। सी # थोड़े dynamic के माध्यम से इसका समर्थन करता है लेकिन मैंने इसे अभ्यास में कभी भी उपयोग नहीं किया है और सामान्य रूप से कीवर्ड वास्तविक कोड में बहुत दुर्लभ है। उदाहरण मुझे याद है कि जेएसओएन पार्सिंग जैसे कुछ से निपटते हैं, जेनेरिक नहीं लिख रहे हैं।

क्या बहु-प्रेषण यह सब आवश्यक है?

आईएमएचओ, मुझे लगता है कि @keean टाइपक्लास/इंटरफेस द्वारा प्रदान किए गए स्थिर एकाधिक प्रेषण के बारे में बोलता है।
यह सी ++ में विधि ओवरलोडिंग द्वारा भी प्रदान किया जाता है (मुझे सी # के लिए पता नहीं है)

आपका मतलब गतिशील एकाधिक प्रेषण है जो संघ प्रकारों के बिना स्थिर भाषाओं में काफी बोझिल है। गतिशील भाषाएं स्थिर प्रकार की जांच (गतिशील भाषाओं के लिए आंशिक प्रकार अनुमान, सी # के "गतिशील" प्रकार के लिए समान) को छोड़कर इस समस्या को दूर करती हैं।

क्या एक प्रकार को "बस" पैरामीटर के रूप में प्रदान किया जा सकता है?

func Append(t, t2 type, arr []t, value t2) []t {
    v := t(value) // conversion
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

@ इनुआर्ट ने लिखा:

क्या एक प्रकार को "बस" पैरामीटर के रूप में प्रदान किया जा सकता है?

संदेहास्पद है कि यह किस हद तक संभव होगा या गो में वांछित होगा

यदि आप सामान्य बाधाओं का समर्थन करते हैं तो आप जो चाहते हैं उसे हासिल किया जा सकता है:

func Append(arr []t, value s) []t  requires Convertible<s,t>{
    v := t(value) // conversion
    return append(arr, v)
}

var arr []int64
v := 0.5

arr = Append(arr, v)

बाधाओं के साथ भी यह संभव होना चाहिए:

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

इसके लायक क्या है, हमारी जीनस भाषा एकाधिक प्रेषण का समर्थन करती है। एक बाधा के लिए मॉडल कई कार्यान्वयन की आपूर्ति कर सकते हैं जिन्हें भेजा जाता है।

मैं समझता हूं कि संकलन समय सुरक्षा के लिए Convertible<s,t> अंकन की आवश्यकता है, लेकिन इसे रनटाइम जांच में अवक्रमित किया जा सकता है

func Append(t, t2 type, arr []t, value t2) []t {
    v, ok := t(value) // conversion
    if !ok {
        panic(...) // or return an err
    }
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

लेकिन यह reflect के लिए सिंटैक्स चीनी की तरह दिखता है।

@Inuart बिंदु यह है कि संकलक संकलन समय पर टाइपक्लास को लागू करने वाले प्रकार की जांच कर सकता है, इसलिए रनटाइम चेक अनावश्यक है। लाभ बेहतर प्रदर्शन है (तथाकथित शून्य लागत अमूर्तता)। यदि यह रनटाइम चेक है तो आप reflect का भी उपयोग कर सकते हैं।

@ क्रेकर

क्या बहु-प्रेषण यह सब आवश्यक है?

मैं इस बारे में बहुत दिमाग में हूं। एक तरफ बहु-प्रेषण (बहु-पैरामीटर प्रकार वर्गों के साथ) अस्तित्व के साथ अच्छी तरह से काम नहीं करता है, जिसे 'गो' 'इंटरफ़ेस मान' कहता है।

type Equals<T> interface {eq(right T) bool}
(left I) eq(right I) bool {return left == right}
(left I) eq(right F) bool {return false}
(left F) eq(right I) bool {return false}
(left F) eq(right F) bool {return left == right}

func main() {
    x := []Equals<?>{I{2}, F{4.0}, I{2}, F{4.0}}
}

हम Equals के स्लाइस को परिभाषित नहीं कर सकते क्योंकि हमारे पास यह इंगित करने का कोई तरीका नहीं है कि दाहिने हाथ का पैरामीटर उसी संग्रह से है। हम हास्केल में भी ऐसा नहीं कर सकते:

data Equals = forall a . IEquals a a => Equals a

यह अच्छा नहीं है क्योंकि यह केवल एक प्रकार की तुलना स्वयं से करने की अनुमति देता है

data Equals = forall a b . IEquals a b => Equals a

यह अच्छा नहीं है क्योंकि हमारे पास b को a (यदि a भी एक संग्रह में है) के समान संग्रह में एक और अस्तित्व के लिए बाध्य करने का कोई तरीका नहीं है।

हालांकि यह एक नए प्रकार के साथ विस्तार करना बहुत आसान बनाता है:

(left K) eq(right I) bool {return false}
(left K) eq(right F) bool {return false}
(left I) eq(right K) bool {return false}
(left F) eq(right K) bool {return false}
(left K) eq(right K) bool {return left == right}

और यह डिफ़ॉल्ट उदाहरणों या विशेषज्ञता के साथ और भी संक्षिप्त होगा।

दूसरी ओर हम इसे 'गो' में फिर से लिख सकते हैं जो अभी काम करता है:

package main

type I struct {v int}
type F struct {v float32}

type EqualsInt interface {eqInt(left I) bool}
func (right I) eqInt (left I) bool {return left == right}
func (right F) eqInt (left I) bool {return false}

type EqualsFloat interface {eqFloat(left F) bool}
func (right I) eqFloat (left F) bool {return false}
func (right F) eqFloat (left F) bool {return left == right}

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

type EqualsLeft interface {eq(right EqualsRight) bool}
func (left I) eq (right EqualsRight) bool {return right.eqInt(left)}
func (left F) eq (right EqualsRight) bool {return right.eqFloat(left)}

type Equals interface {
    EqualsLeft
    EqualsRight
}

func main() {
    x := []Equals{I{2}, F{4.0}, I{2}, F{4.0}}
    println(x[0].eq(x[1]))
    println(x[1].eq(x[0]))
    println(x[0].eq(x[2]))
    println(x[1].eq(x[3]))
}

यह अस्तित्व (इंटरफ़ेस वैल्यू) के साथ अच्छी तरह से काम करता है, हालांकि यह बहुत अधिक जटिल है, यह देखना कठिन है कि क्या हो रहा है और यह कैसे काम करता है, और इसका बड़ा प्रतिबंध है कि हमें प्रति प्रकार एक इंटरफ़ेस की आवश्यकता है और हमें स्वीकार्य कोड को हार्ड कोड करने की आवश्यकता है दाहिने हाथ की ओर इस तरह के प्रकार:

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

जिसका अर्थ है कि हमें एक नया प्रकार जोड़ने के लिए पुस्तकालय स्रोत को संशोधित करना होगा क्योंकि इंटरफ़ेस EqualsRight एक्स्टेंसिबल नहीं है।

तो बहु-पैरामीटर इंटरफेस के बिना हम समानता जैसे एक्स्टेंसिबल जेनेरिक ऑपरेटरों को परिभाषित नहीं कर सकते हैं। बहु-पैरामीटर इंटरफेस के साथ अस्तित्व (इंटरफ़ेस मान) समस्याग्रस्त हो जाते हैं।

बहुत सारे प्रस्तावित सिंटैक्स (वाक्यविन्यास?) Blah[E] के साथ मेरा मुख्य मुद्दा यह है कि अंतर्निहित प्रकार जेनरिक युक्त कोई जानकारी नहीं दिखाता है।

उदाहरण के लिए:

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

इसका मतलब है कि हम एक नया प्रकार घोषित कर रहे हैं जो अंतर्निहित प्रकार पर अधिक जानकारी जोड़ता है। क्या किसी अन्य प्रकार के आधार पर किसी नाम को परिभाषित करने की type घोषणा की बात नहीं है?

मैं की पंक्ति के साथ एक वाक्यविन्यास का प्रस्ताव दूंगा

type Comparer interface[C] {
    Compare(other C) bool
}

इसका मतलब यह है कि वास्तव में Comparer केवल interface[C] { ... } पर आधारित एक प्रकार है, और interface[C] { ... } निश्चित रूप से interface { ... } से इसका अपना अलग प्रकार है। यह आपको एक सामान्य इंटरफ़ेस का उपयोग करने की अनुमति देता है, यदि आप चाहें तो इसका नाम लिए बिना (जिसे सामान्य इंटरफेस के साथ अनुमति दी जाती है)। मुझे लगता है कि यह समाधान थोड़ा अधिक सहज है और गो के टाइप सिस्टम के साथ अच्छी तरह से काम करता है, हालांकि अगर मैं गलत हूं तो कृपया मुझे सुधारें।

नोट: एक सामान्य प्रकार की घोषणा केवल निम्नलिखित सिंटैक्स वाले इंटरफेस, स्ट्रक्चर और फंक पर ही स्वीकार्य होगी:
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

फिर जेनरिक के "कार्यान्वयन" में निम्नलिखित सिंटैक्स होंगे:
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

और कुछ उदाहरणों के साथ इसे थोड़ा और स्पष्ट करने के लिए:

इंटरफेस

package add

type Adder interface[E] {
    // Adds the element and returns the size
    Add(elem E) int
}

// Adds the integer 5 to any implementation of Adder[int].
func AddFiveTo(a Adder[int]) int {
    return a.Add(5)
}

स्ट्रक्चर्स

package heap

type List struct[T] {
    slice []T
}

func (l *List) Add(elem T) { // T is a type defined by the receiver
    l.slice = append(l.slice, elem)
}

कार्यों

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

यह Go2 अनुबंधों के मसौदे के जवाब में है और मैं इसके सिंटैक्स का उपयोग करूंगा, लेकिन मैं इसे यहां पोस्ट कर रहा हूं क्योंकि यह पैरामीट्रिक बहुरूपता के किसी भी प्रस्ताव पर लागू होता है।

प्रकार के मापदंडों को एम्बेड करने की अनुमति नहीं दी जानी चाहिए।

विचार करना

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

कुछ मनमाने प्रकार के लिए R और कुछ मनमाने अनुबंध C जिसमें Foo() शामिल नहीं है।

T में C के लिए आवश्यक सभी चयनकर्ता होंगे लेकिन T के एक विशेष इंस्टेंटेशन में अन्य चयनकर्ता भी शामिल हो सकते हैं, जिनमें Foo भी शामिल है।

मान लें कि Bar एक संरचना है, जो C के तहत स्वीकार्य है, जिसमें Foo नाम की एक फ़ील्ड है।

X(Bar) एक अवैध तात्कालिकता हो सकती है। अनुबंध को निर्दिष्ट करने के तरीके के बिना कि एक प्रकार का चयनकर्ता नहीं है, यह एक अनुमानित संपत्ति होनी चाहिए।

X(Bar) Foo X(Bar).R.Foo रूप में हल करना जारी रख सकते हैं। यह सामान्य प्रकार के लेखन को संभव बनाता है लेकिन संकल्प नियमों के नाइटपिकरी से अपरिचित पाठक को भ्रमित कर सकता है। X के तरीकों के बाहर, चयनकर्ता अस्पष्ट रहेगा, जबकि interface { Foo() } X X की कुछ तात्कालिकताएं होंगी इसे संतुष्ट नहीं करते।

एक प्रकार के पैरामीटर को एम्बेड करने की अनुमति देना आसान नहीं है।

(यदि इसकी अनुमति दी जानी है, हालांकि, फ़ील्ड का नाम T होगा, उसी कारण से कि $#$ type S = io.Reader $#$ के रूप में परिभाषित एम्बेडेड S का फ़ील्ड नाम S है Reader नहीं बल्कि इसलिए भी कि T को तत्काल करने वाले प्रकार को नाम रखने की आवश्यकता नहीं है।)

@jimmyfrasche मुझे लगता है कि सामान्य प्रकार वाले एम्बेडेड फ़ील्ड पर्याप्त उपयोगी होते हैं कि उन्हें अनुमति देना अच्छा होगा, भले ही स्थानों में थोड़ी अजीबता हो। मेरा सुझाव सभी सामान्य कोड में यह मानना ​​​​होगा कि एम्बेडेड प्रकार ने हर संभव स्तर पर सभी संभावित क्षेत्रों और विधियों को परिभाषित किया है, ताकि सामान्य कोड के भीतर सभी एम्बेडेड विधियों और गैर-जेनेरिक प्रकारों के क्षेत्र मिटा दिए जाएं।

तो दिया गया:

type R struct(type T) {
    io.Reader
    T
}

आर पर विधियां रीडर के माध्यम से अप्रत्यक्ष किए बिना आर पर रीड को आमंत्रित करने में सक्षम नहीं होंगी। उदाहरण के लिए:

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

केवल नीचे की ओर जो मैं देख सकता हूं वह यह है कि गतिशील प्रकार में स्थिर प्रकार की तुलना में अधिक सदस्य हो सकते हैं। उदाहरण के लिए:

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@रोगपेप्पे

केवल नीचे की ओर जो मैं देख सकता हूं वह यह है कि गतिशील प्रकार में स्थिर प्रकार की तुलना में अधिक सदस्य हो सकते हैं।

यह सीधे टाइप पैरामीटर के मामले में है, इसलिए मुझे लगता है कि यह पैरामीट्रिक प्रकारों के साथ भी ठीक होना चाहिए। मुझे लगता है कि समस्या का समाधान @jimmyfrasche प्रस्तुत किया गया हो सकता है कि अनुबंध में पैरामीटरयुक्त प्रकार के वांछित विधि सेट को रखा जाए।

contract C(t T) {
  interface { Foo() } (X(T){})
  // ...
}

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

यह Foo को सीधे X पर कॉल करने की अनुमति देगा। बेशक, यह "अनुबंधों में कोई स्थानीय नाम नहीं" नियम से दूर चला जाएगा ...

@stevenblenkinsop हम्म, यह संभव है, अगर अजीब है, तो ऐसा करने के लिए X का जिक्र किए बिना

contract C(t T) {
  struct{ R; T }{}.Foo
}

C अभी भी X के कार्यान्वयन के लिए बाध्य है, हालांकि थोड़ा अधिक ढीला है।

यदि आप ऐसा नहीं करते हैं, और आप लिखते हैं

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

क्या यह संकलित करता है? यह @rogpeppe के नियम के तहत नहीं होगा, ऐसा लगता है कि जब आप अनुबंध में गारंटी नहीं देते हैं तो इसे भी अपनाया जाना चाहिए। लेकिन क्या यह केवल तभी लागू होता है जब आप एक प्रकार के तर्क को बिना पर्याप्त अनुबंध के या सभी एम्बेडिंग के लिए एम्बेड करते हैं?

इसे अस्वीकार करना आसान होगा।

Go2 के मसौदे की घोषणा से पहले मैंने इस प्रस्ताव पर काम करना शुरू कर दिया था।

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

यह @ianlancetaylor के पहले के प्रस्तावों के वाक्य-विन्यास पर विस्तार करता है, जैसा कि मेरे शुरू होने पर उपलब्ध था। यह मौलिक नहीं है। इसे (type T आदि सिंटैक्स या समकक्ष कुछ द्वारा प्रतिस्थापित किया जा सकता है। मुझे शब्दार्थ के लिए एक संकेतन के रूप में बस कुछ वाक्य रचना की आवश्यकता थी।

यह यहां स्थित है: https://gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

नियम यह होना चाहिए कि एम्बेडेड प्रकार पैरामीटर की तुलना में अधिक गहराई से प्रचारित किसी भी विधि को तब तक नहीं कहा जा सकता जब तक (1) प्रकार तर्क की पहचान ज्ञात न हो या (2) विधि को बाहरी पर कॉल करने योग्य माना जाता है प्रकार पैरामीटर को बाधित करने वाले अनुबंध द्वारा टाइप करें। संकलक गहराई पर ऊपरी और निचली सीमाओं को भी निर्धारित कर सकता है जो एक प्रचारित विधि बाहरी प्रकार O के भीतर होनी चाहिए, और यह निर्धारित करने के लिए उनका उपयोग करें कि विधि उस प्रकार पर कॉल करने योग्य है या नहीं जो एम्बेड करता है O , यानी अन्य प्रचारित तरीकों के साथ संघर्ष की संभावना है या नहीं। कुछ इसी तरह के किसी भी प्रकार के पैरामीटर के लिए भी लागू होगा जिसे कॉल करने योग्य विधियों के लिए कहा जाता है, जहां प्रकार पैरामीटर के भीतर विधियों की गहराई सीमा [0, inf) होगी।

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

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

type Wrapper(type T) { T }

आप सभी मामलों में इंटरफ़ेस में *Wrapper(T) डाल सकते हैं यदि आपका अनुबंध कहता है कि यह इंटरफ़ेस को संतुष्ट करता है।

क्या आप बस नहीं कर सकते

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

मैं उस मामले को संभालने की कोशिश कर रहा हूं जहां कोई कॉल करता है

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

यह काम नहीं करेगा क्योंकि S को Interface में नहीं बदला जा सकता, केवल *S ही कर सकता है।

जाहिर है, जवाब "ऐसा मत करो" हो सकता है। हालाँकि, अनुबंध प्रस्ताव अनुबंधों का वर्णन करता है जैसे:

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

S ऑटो-एड्रेसिंग के कारण इस अनुबंध को पूरा करेगा, जैसा कि *S होगा। जो मैं संबोधित करने की कोशिश कर रहा हूं वह अनुबंधों में विधि कॉल और इंटरफ़ेस रूपांतरणों के बीच क्षमता अंतर है।

वैसे भी, यह एक स्पर्शरेखा है, जो एम्बेडिंग प्रकार पैरामीटर के लिए एक संभावित उपयोग दिखा रहा है।

फिर से एम्बेड करना, मुझे लगता है कि "एक संरचना में एम्बेड कर सकते हैं" एक और प्रतिबंध है जिसे अनुबंधों को अनुमति देने पर कब्जा करना होगा।

विचार करना:

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
}

type Embedded(type First, Second Embeddable) struct {
        First
        Second
}

// Error: First and Second both provide method Read.
// That must be diagnosed to the Embeddable contract, not the definition of Embedded itself.
type Boom = Embedded(*bytes.Buffer, *strings.Reader)

@bcmills अस्पष्ट चयनकर्ताओं के साथ एम्बेडिंग प्रकार की अनुमति है, इसलिए मुझे यकीन नहीं है कि उस अनुबंध की व्याख्या कैसे की जानी चाहिए।

किसी भी मामले में, यदि आप केवल ज्ञात प्रकारों को ही एम्बेड कर रहे हैं, तो यह ठीक है। यदि आप केवल प्रकार के पैरामीटर एम्बेड कर रहे हैं, तो यह ठीक है। एकमात्र मामला जो अजीब हो जाता है जब आप एक या अधिक ज्ञात प्रकार और एक या अधिक प्रकार के पैरामीटर एम्बेड करते हैं और तब केवल जब ज्ञात प्रकार के चयनकर्ता और प्रकार के तर्क अलग नहीं होते हैं

@bcmills अस्पष्ट चयनकर्ताओं के साथ एम्बेडिंग प्रकार की अनुमति है, इसलिए मुझे यकीन नहीं है कि उस अनुबंध की व्याख्या कैसे की जानी चाहिए।

हम्म, अच्छा बिंदु। मुझे त्रुटि ट्रिगर करने के लिए एक और बाधा याद आ रही है।¹

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

¹ https://play.golang.org/p/3wSg5aRjcQc

इसके लिए X या Y में से एक की आवश्यकता है लेकिन दोनों को io.Reader नहीं होना चाहिए। यह दिलचस्प है कि अनुबंध प्रणाली इसकी अनुमति देने के लिए पर्याप्त अभिव्यंजक है। मुझे खुशी है कि मुझे ऐसे जानवर के लिए प्रकार के अनुमान के नियमों का पता लगाने की जरूरत नहीं है।

लेकिन वास्तव में यह समस्या नहीं है।

यह तब होता है जब आप करते हैं

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

यह संकलित करने में विफल होना चाहिए क्योंकि T में Read चयनकर्ता हो सकता है जब तक कि C न हो

struct{ io.Reader; T }.Read

लेकिन फिर क्या नियम हैं जब C यह सुनिश्चित नहीं करता है कि चयनकर्ता सेट अलग हैं और S चयनकर्ताओं का संदर्भ नहीं देता है? क्या प्रत्येक तात्कालिकता S के लिए एक अस्पष्ट चयनकर्ता बनाने वाले प्रकारों को छोड़कर एक इंटरफ़ेस को संतुष्ट करना संभव है?

क्या हर तात्कालिकता S के लिए एक अस्पष्ट चयनकर्ता बनाने वाले प्रकारों को छोड़कर एक इंटरफ़ेस को संतुष्ट करना संभव है?

हाँ, ऐसा ही प्रतीत होता है। मुझे आश्चर्य है कि क्या इसका मतलब कुछ गहरा है ...

मैं अविश्वसनीय रूप से बुरा कुछ भी निर्माण करने में सक्षम नहीं हूं, लेकिन विषमता काफी अप्रिय है और मुझे असहज महसूस कराती है:

type I interface { /* ... */ }
a := G(A) // ok, A satisfies contract
var _ I = a // ok, no selector overlap
b := G(B) // ok, B satisfies contract
var _ = b // error, selector overlap

मैं त्रुटि संदेशों के बारे में चिंतित हूं जब G0(B) एक G1(B) का उपयोग करता है। . . Gn(B) का उपयोग करता है और Gn वह है जो त्रुटि का कारण बनता है। . . .

FTR, एम्बेडिंग के साथ टाइप-एरर्स को ट्रिगर करने के लिए आपको अस्पष्ट चयनकर्ताओं की परेशानी से गुजरने की आवश्यकता नहीं है।

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

आप मान रहे हैं कि एम्बेडेड फ़ील्ड नाम तर्क प्रकार पर आधारित है, जबकि यह एम्बेडेड प्रकार पैरामीटर का नाम होने की अधिक संभावना है। यह ऐसा है जब आप एक प्रकार का उपनाम एम्बेड करते हैं और फ़ील्ड का नाम उपनाम होता है न कि उस प्रकार के उपनाम के नाम से।

यह वास्तव में पैरामीटरयुक्त प्रकारों पर अनुभाग में मसौदा डिजाइन में निर्दिष्ट है:

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

type Lockable(type T) struct {
    T
    mu sync.Mutex
}

func (l *Lockable(T)) Get() T {
    l.mu.Lock()
    defer l.mu.Unlock()
    return l.T
}

(नोट: यदि आप विधि घोषणा में लॉक करने योग्य (एक्स) लिखते हैं तो यह खराब काम करता है: क्या विधि को एलटी या एलएक्स वापस करना चाहिए? शायद हमें किसी संरचना में एक प्रकार पैरामीटर एम्बेड करने पर प्रतिबंध लगाना चाहिए।)

मैं अभी यहाँ किनारे पर बैठा हूँ और देख रहा हूँ। लेकिन थोड़ी चिंता भी हो रही है।

एक बात कहने में मुझे कोई शर्म नहीं है कि इस चर्चा का 90% मेरे सिर पर है।

ऐसा लगता है कि जेनेरिक, या पैरामीट्रिक पॉलीमॉर्फिज्म क्या है, यह जाने बिना सॉफ्टवेयर लिखने से 20 साल की कमाई ने मुझे काम करने से नहीं रोका।

अफसोस की बात है कि मैंने गो सीखने के लिए लगभग एक साल पहले ही समय लिया था। मैंने यह गलत धारणा बना ली थी कि यह एक कठिन सीखने की अवस्था थी, और इसे उत्पादक बनने में बहुत समय लगेगा।

मैं और अधिक गलत नहीं हो सकता था।

मैं एक माइक्रोसर्विस बनाने के लिए पर्याप्त गो सीखने में सक्षम था जिसने नोड.जेएस सेवा को पूरी तरह से नष्ट कर दिया था, मुझे एक सप्ताहांत से भी कम समय में प्रदर्शन की समस्या हो रही थी।

विडंबना यह है कि मैं बस खेल रहा था। मैं गो के साथ दुनिया को जीतने के बारे में विशेष रूप से गंभीर नहीं था।

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

और यही वह चीज है जो मुझे गो के बारे में पसंद है। यह बहुत तेज़ है..... सीखने के लिए। हम सभी यहां इसकी प्रदर्शन क्षमताओं के बारे में जानते हैं। लेकिन जिस गति से इसे सीखा जा सकता है वह उन 8 अन्य भाषाओं से बेजोड़ है जिन्हें मैंने वर्षों से सीखा है।

तब से मैं गो की स्तुति गा रहा हूं, और इसके प्यार में पड़ने के लिए 4 और देव मिल गए हैं। मैं बस उनके साथ कुछ घंटों के लिए बैठता हूं और कुछ बनाता हूं। परिणाम अपने लिए बोलते हैं।

सरलता, और सीखने की गति। ये भाषा की असली हत्यारा विशेषताएं हैं।

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

इसलिए, मुझे उम्मीद है कि गो टीम दो बातों पर ध्यान दे सकती है:

1) हम किस दिन-प्रतिदिन की समस्या को हल करना चाह रहे हैं?

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

रसोई की किताब की शैली के उदाहरण हर दिन के ऐसे कार्य हैं जो समस्याग्रस्त हैं, इस उदाहरण के साथ कि इन भाषा परिवर्तन प्रस्तावों के साथ उन्हें कैसे बेहतर बनाया जा सकता है।

2) इसे सरल रखें, जैसे कि Go . की अन्य सभी बेहतरीन विशेषताएं

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

शायद ऐसी उन्नत सुविधाओं को सक्षम करने के लिए एक कंपाइलर तर्क? '--कट्टर'

अगर हम कंपाइलर के प्रदर्शन को नकारात्मक रूप से प्रभावित करते हैं तो मुझे वास्तव में दुख होगा। बस 'नहीं' कहो

और यही वह चीज है जो मुझे गो के बारे में पसंद है। यह बहुत तेज़ है..... सीखने के लिए। हम सभी यहां इसकी प्रदर्शन क्षमताओं के बारे में जानते हैं। लेकिन जिस गति से इसे सीखा जा सकता है वह उन 8 अन्य भाषाओं से बेजोड़ है जिन्हें मैंने वर्षों से सीखा है।

मैं पूरी तरह से सहमत हुँ। पूरी तरह से संकलित भाषा में सरलता के साथ शक्ति का संयोजन कुछ ऐसा है जो पूरी तरह से अद्वितीय है। मैं निश्चित रूप से नहीं चाहता कि गो इसे खो दे, और जितना मुझे जेनरिक चाहिए, मुझे नहीं लगता कि वे उस कीमत पर इसके लायक हैं। हालांकि, मुझे नहीं लगता कि इसे खोना जरूरी है।

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

मेरे पास जेनरिक के लिए दो मुख्य प्राथमिक उपयोग के मामले हैं: बाइनरी ट्री, सेट, और sync.Map जैसे जटिल डेटा संरचनाओं का टाइप-सुरक्षित बॉयलरप्लेट उन्मूलन, और _compile-time_ टाइप-सुरक्षित फ़ंक्शन लिखने की क्षमता जो आधारित संचालित होते हैं विशुद्ध रूप से उनके तर्कों की कार्यक्षमता पर, न कि स्मृति में उनके लेआउट पर। वहाँ कुछ कट्टर चीजें हैं जिन्हें करने में मुझे कोई आपत्ति नहीं होगी, लेकिन मुझे कोई आपत्ति नहीं होगी अगर भाषा की सादगी को पूरी तरह से तोड़े बिना उनके लिए समर्थन जोड़ना असंभव है।

ईमानदार होने के लिए, भाषा में पहले से ही ऐसी विशेषताएं हैं जो काफी अपमानजनक हैं। प्राथमिक कारण है कि वे _not_ दुर्व्यवहार कर रहे हैं, मुझे लगता है कि अक्सर, 'मुहावरेदार' कोड लिखने की गो संस्कृति है, जो मानक पुस्तकालय के साथ संयुक्त है, अधिकांश भाग के लिए ऐसे कोड के उदाहरण खोजने में आसान, आसान प्रदान करता है। मानक पुस्तकालय में जेनरिक का अच्छा उपयोग करना निश्चित रूप से प्राथमिकता होनी चाहिए जब उन्हें लागू किया जाए।

@camstuart

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

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

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

इससे भी बेहतर, यह सब तकनीकी रूप से अभी गो में किया जा सकता है, लेकिन केवल कुछ, संभावित रूप से प्रमुख, रनटाइम ओवरहेड के साथ संकलन-समय प्रकार-सुरक्षा _and_ के पूर्ण नुकसान के साथ। जेनरिक आपको इनमें से किसी भी डाउनसाइड के बिना ऐसा करने देता है।

सामान्य कार्य कार्यान्वयन:

/*

* "generic" is a KIND of types, just like "struct", "map", "interface", etc...
* "T" is a generic type (a type of kind generic).
* var t = T{int} is a value of type T, values of generic types looks like a "normal" type

*/

type T generic {
    int
    float64
    string
}

func Sum(a, b T{}) T{} {
    return a + b
}

फंक्शन कॉलर:

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

सामान्य संरचना कार्यान्वयन:

type ItemT generic {
    interface{}
}

type List struct {
    l []ItemT{}
}

func NewList(t ItemT) *List {
    l := make([]t)
    return &List{l}
}

func (p *List) Push(item ItemT{}) {
    p.l = append(p.l, item)
}

फोन करने वाला:

list := NewList(ItemT{int})
list.Push(42)

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

हो सकता है कि मैं गो के वर्तमान संस्करण के साथ और अधिक अनुभवी हूं, लेकिन मेरे लिए यह सी ++ के लिए एक रिग्रेशन की तरह लगता है जिसमें अन्य लोगों द्वारा लिखे गए कोड को समझना अधिक कठिन होता है। प्रकारों के लिए क्लासिक T प्लेसहोल्डर यह समझना इतना कठिन बना देता है कि कोई फ़ंक्शन क्या करने का प्रयास कर रहा है।

मुझे पता है कि यह एक लोकप्रिय फीचर अनुरोध है, इसलिए अगर यह जमीन पर आता है तो मैं इससे निपट सकता हूं, लेकिन मैं अपने 2 सेंट (राय) जोड़ना चाहता था।

@jlubawy
क्या आप एक और तरीका जानते हैं कि मुझे कभी भी एक लिंक्ड सूची या क्विकॉर्ट एल्गोरिदम लागू करने की ज़रूरत नहीं है? जैसा कि अलेक्जेंडर स्टेपानोव बताते हैं कि अधिकांश प्रोग्रामर "न्यूनतम" और "अधिकतम" कार्यों को सही ढंग से परिभाषित नहीं कर सकते हैं, इसलिए हमें बहुत अधिक डिबगिंग समय के बिना अधिक जटिल एल्गोरिदम को सही ढंग से लागू करने की क्या उम्मीद है। मैं पुस्तकालय से इन एल्गोरिदम के मानक संस्करणों को बहुत अधिक खींचूंगा और मेरे पास मौजूद प्रकारों पर लागू होगा। वहाँ क्या विकल्प है?

@jlubawy

या टेम्प्लेटिंग, या जिसे आप इसे कॉल करना चाहते हैं

सब कुछ कार्यान्वयन पर निर्भर करता है। यदि हम C++ टेम्प्लेट के बारे में बात कर रहे हैं तो हाँ, उन्हें सामान्य रूप से समझना मुश्किल है। उन्हें लिखना भी मुश्किल है। दूसरी ओर, यदि हम C# जेनरिक लेते हैं तो वह पूरी तरह से दूसरी बात है। अवधारणा ही यहाँ कोई समस्या नहीं है।

यदि आप नहीं जानते हैं, तो गो टीम ने गो 2.0 के मसौदे की घोषणा की है:
https://golang.org/s/go2designs

गो 2.0 (अनुबंध) में जेनरिक डिजाइन के लिए एक मसौदा है। आप उनके विकी पर एक नज़र डालना और प्रतिक्रिया देना चाह सकते हैं।

यह प्रासंगिक खंड:

जेनेरिक्स

• अवलोकन
• ड्राफ्ट डिजाइन
• विकी प्रतिक्रिया पृष्ठ

मसौदा पढ़ने के बाद, मैं पूछता हूं:

क्यों

टी: जोड़ने योग्य

मतलब "एक प्रकार टी अनुबंध को लागू करने योग्य"? एक नया क्यों जोड़ रहे हैं
अवधारणा जब हमारे पास इसके लिए पहले से ही इंटरफेस हैं? इंटरफेस असाइनमेंट है
निर्माण समय में चेक किया गया है, इसलिए हमारे पास पहले से ही किसी की आवश्यकता नहीं है
अतिरिक्त अवधारणा यहाँ। हम इस शब्द का उपयोग कुछ इस तरह कहने के लिए कर सकते हैं: Any
इंटरफ़ेस Addable को लागू करने वाला T टाइप करें। इसके अतिरिक्त, टी:_ या टी: कोई भी
(कोई भी एक विशेष कीवर्ड या इंटरफ़ेस का एक अंतर्निहित उपनाम {} होने के नाते) करेगा
चाल।

बस मुझे नहीं पता कि इस तरह की अधिकांश चीजों को फिर से क्यों लागू किया जाए। नहीं बनाता है
सेंस और विल बेमानी होगा (जैसा कि बेमानी है त्रुटियों की नई हैंडलिंग wrt
आतंक से निपटने)।

2018-09-14 6:15 जीएमटी-05:00 कोआला येउंग नोटिफिकेशन @github.com :

यदि आप नहीं जानते हैं, तो गो टीम ने गो 2.0 के मसौदे की घोषणा की है:
https://golang.org/s/go2designs

गो 2.0 (अनुबंध) में जेनरिक डिजाइन के लिए एक मसौदा है। आप चाहेंगे
देखने और प्रतिक्रिया देने के लिए
उनके विकी पर https://github.com/golang/go/wiki/Go2GenericsFeedback
https://github.com/golang/go/wiki/Go2GenericsFeedback ।

यह प्रासंगिक खंड:

जेनेरिक्स

• अवलोकन
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [ड्राफ़्ट डिज़ाइन] (https://go.googlesource.com/proposal/+/master/design/
  go2draft-contracts.md)
• विकी प्रतिक्रिया पृष्ठ
  https://github.com/golang/go/wiki/Go2GenericsFeedback

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-421326634 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
ट्रिपलमिंट में उपयोग किए जाने वाले मेल हस्ताक्षरों के लिए यह एक परीक्षण है

संपादित करें: "[...] अगर आपको किसी विशेष आवश्यकता की आवश्यकता नहीं है तो चाल चलेंगे
प्रकार तर्क"।

2018-09-17 11:10 जीएमटी-05:00 लुइस मासुएली [email protected] :

मसौदा पढ़ने के बाद, मैं पूछता हूं:

क्यों

टी: जोड़ने योग्य

मतलब "एक प्रकार टी अनुबंध को लागू करने योग्य"? एक नया क्यों जोड़ रहे हैं
अवधारणा जब हमारे पास इसके लिए पहले से ही इंटरफेस हैं? इंटरफेस असाइनमेंट है
निर्माण समय में चेक किया गया है, इसलिए हमारे पास पहले से ही किसी की आवश्यकता नहीं है
अतिरिक्त अवधारणा यहाँ। हम इस शब्द का उपयोग कुछ इस तरह कहने के लिए कर सकते हैं: Any
इंटरफ़ेस Addable को लागू करने वाला T टाइप करें। इसके अतिरिक्त, टी:_ या टी: कोई भी
(कोई भी एक विशेष कीवर्ड या इंटरफ़ेस का एक अंतर्निहित उपनाम {} होने के नाते) करेगा
चाल।

बस मुझे नहीं पता कि इस तरह की अधिकांश चीजों को फिर से क्यों लागू किया जाए। नहीं बनाता है
सेंस और विल बेमानी होगा (जैसा कि बेमानी है त्रुटियों की नई हैंडलिंग wrt
आतंक से निपटने)।

2018-09-14 6:15 जीएमटी-05:00 कोआला येउंग नोटिफिकेशन @github.com :

यदि आप नहीं जानते हैं, तो गो टीम ने गो 2.0 के मसौदे की घोषणा की है:
https://golang.org/s/go2designs

गो 2.0 (अनुबंध) में जेनरिक डिजाइन के लिए एक मसौदा है। आप कर सकते हैं
देखना चाहते हैं और प्रतिक्रिया देना चाहते हैं
उनके विकी पर https://github.com/golang/go/wiki/Go2GenericsFeedback
https://github.com/golang/go/wiki/Go2GenericsFeedback ।

यह प्रासंगिक खंड:

जेनेरिक्स

• अवलोकन
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [ड्राफ़्ट डिज़ाइन] (https://go.googlesource.com/p
  roposal/+/master/design/go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  )
• विकी प्रतिक्रिया पृष्ठ
  https://github.com/golang/go/wiki/Go2GenericsFeedback

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/15292#issuecomment-421326634 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
ट्रिपलमिंट में उपयोग किए जाने वाले मेल हस्ताक्षरों के लिए यह एक परीक्षण है

--
ट्रिपलमिंट में उपयोग किए जाने वाले मेल हस्ताक्षरों के लिए यह एक परीक्षण है

@ luismasuelli-jobsity अगर मैं गो में सामान्य कार्यान्वयन के इतिहास को सही ढंग से पढ़ता हूं, तो ऐसा लगता है कि अनुबंधों को पेश करने का कारण यह है कि वे इंटरफेस में ऑपरेटर ओवरलोडिंग नहीं चाहते थे।

एक पूर्व प्रस्ताव जिसे अंततः अस्वीकार कर दिया गया था, पैरामीट्रिक बहुरूपता को बाधित करने के लिए प्रयुक्त इंटरफेस को अस्वीकार कर दिया गया था, लेकिन ऐसा लगता है कि आप ऐसे कार्यों में '+' जैसे सामान्य ऑपरेटरों का उपयोग नहीं कर सके क्योंकि यह एक इंटरफ़ेस में परिभाषित नहीं है। अनुबंध आपको t == t या t + t लिखने की अनुमति देते हैं ताकि आप इंगित कर सकें कि प्रकार को समानता या जोड़ आदि का समर्थन करना चाहिए।

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

क्यों T:Addable का अर्थ है "एक प्रकार का टी जो अनुबंध को लागू करने योग्य है"?

वास्तव में इसका मतलब यह नहीं है; यह सिर्फ एक प्रकार के तर्क के लिए ऐसा दिखता है। मसौदे में कहीं और यह टिप्पणी करता है कि आपके पास प्रति फ़ंक्शन केवल एक अनुबंध हो सकता है, और यही वह जगह है जहां मुख्य अंतर आता है। अनुबंध वास्तव में फ़ंक्शन के प्रकारों के बारे में बयान हैं, न कि केवल स्वतंत्र रूप से। उदाहरण के लिए, यदि आपके पास

func Example(type K, V someContract)(k K, v V) V

आप कुछ ऐसा कर सकते हैं

contract someContract(k K, v V) {
  k.someMethod(v)
}

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

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

यह एक प्रकार से अटपटा है। अनुबंध सिंटैक्स आपको अभी भी ऐसा करने की अनुमति देता है यदि आपको इसकी आवश्यकता है, हालांकि, क्योंकि अनुबंध के 'तर्क' संकलक द्वारा स्वतः भरे जाते हैं यदि अनुबंध में उनमें से समान संख्या होती है क्योंकि फ़ंक्शन पैरामीटर टाइप करता है। आप उन्हें मैन्युअल रूप से निर्दिष्ट कर सकते हैं यदि आप चाहते हैं, हालांकि, जिसका अर्थ है कि यदि आप वास्तव में चाहते हैं तो आप func Example(type K, V someContract(K, V))(k K, v V) V कर सकते हैं, हालांकि यह इस स्थिति में विशेष रूप से उपयोगी नहीं है।

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

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

उपरोक्त जैसा ही होगा। हालाँकि, नकारात्मक पक्ष यह है कि अनुबंध पुन: उपयोग योग्य नहीं होंगे और आप अनुबंध के तर्कों को मैन्युअल रूप से निर्दिष्ट करने की क्षमता खो देते हैं।

संपादित करें: आगे यह दिखाने के लिए कि वे उत्सुकता से दोहराए जाने वाले पैटर्न को क्यों हल करना चाहते हैं, सबसे छोटी पथ समस्या पर विचार करें जिसका वे जिक्र करते रहे। पैरामीटरयुक्त इंटरफेस के साथ, परिभाषा हवा की तरह दिखती है

type E(Node) interface {
  Nodes() []Node
}

type N(Edge) interface {
  Edges() (from, to Edge)
}

type Graph(type Node: N(Edge), Edge: E(Node)) struct { ... }
func New(type Node: N(Edge), Edge: E(Node))(nodes []Node) *Graph(Node, Edge) { ... }
func (*Graph(Node, Edge)) ShortestPath(from, to Node) []Edge { ... }

व्यक्तिगत रूप से, मुझे यह पसंद है कि कार्यों के लिए अनुबंध निर्दिष्ट किए जाते हैं। मैं वास्तविक अनुबंध विनिर्देश के रूप में केवल 'सामान्य' कार्य निकायों को रखने के लिए उत्सुक नहीं हूं, लेकिन मुझे लगता है कि कुछ प्रकार की संभावित समस्याओं को हल किया जा सकता है जो किसी प्रकार के गोफएमटी-जैसे सरलीकृत को पेश करते हैं जो आपके लिए अनुबंधों को स्वत: सरल करता है, हटा रहा है बाहरी हिस्से। फिर आप _could_ इसमें एक फंक्शन बॉडी को कॉपी कर सकते हैं, इसे सरल बना सकते हैं, और इसे वहां से संशोधित कर सकते हैं। मुझे यकीन नहीं है कि इसे लागू करना कितना संभव होगा, हालांकि, दुर्भाग्य से।

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

मुझे "सीआरटीपी" संस्करण बहुत स्पष्ट, अधिक स्पष्ट, और काम करने में आसान लगता है (अनुबंध बनाने की कोई आवश्यकता नहीं है जो केवल चर के एक सेट पर पूर्व-मौजूदा अनुबंधों के बीच संबंध को परिभाषित करने के लिए मौजूद है)। बेशक, यह विचार के साथ परिचित होने के कई वर्षों का हो सकता है।

स्पष्टीकरण। ड्राफ्ट डिजाइन के अनुसार, अनुबंध को कार्यों और प्रकारों दोनों पर लागू किया जा सकता है।

"""
यह यकीनन सरल है यदि आपको केवल इंटरफेस या अनुबंधों का उपयोग करने की आवश्यकता है, लेकिन अधिक जटिल यदि आपको दोनों को एक साथ उपयोग करने की आवश्यकता है।
"""

जब तक वे आपको एक अनुबंध के अंदर, एक या एक से अधिक इंटरफेस (केवल ऑपरेटरों और कार्यों के बजाय, इस प्रकार DRY की अनुमति देते हैं) को संदर्भित करने की अनुमति देते हैं, यह मुद्दा (और मेरा दावा) हल हो जाएगा। एक मौका है कि मैंने अनुबंध सामग्री को गलत तरीके से पढ़ा या पूरी तरह से नहीं पढ़ा, और यह भी एक मौका है कि उक्त सुविधा समर्थित है और मैंने इसे नोटिस नहीं किया। अगर ऐसा नहीं है तो होना चाहिए।

क्या आप निम्न कार्य नहीं कर सकते?

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

आप एक ऐसे इंटरफ़ेस का उपयोग नहीं कर सकते हैं जो इस प्रतिबंध के कारण कहीं और घोषित किया गया है कि आप उसी पैकेज से पहचानकर्ताओं को संदर्भित नहीं कर सकते हैं जिसमें अनुबंध घोषित किया गया है, लेकिन आप ऐसा कर सकते हैं। या वे उस प्रतिबंध को हटा सकते थे; यह थोड़ा मनमाना लगता है।

@DeedleFake नहीं, क्योंकि किसी भी इंटरफ़ेस प्रकार को टाइप-जोर दिया जा सकता है (और फिर रनटाइम पर संभावित रूप से घबराहट होती है, लेकिन अनुबंध निष्पादित नहीं होते हैं)। लेकिन आप इसके बजाय एक असाइनमेंट का उपयोग कर सकते हैं।

t.(someInterface) का अर्थ यह भी होगा कि यह एक इंटरफ़ेस होना चाहिए