स्कैला (कम से कम JVM पर) स्कैला में संशोधित जेनेरिक जावा संगतता के लिए type erasure का उपयोग करता है। यह featurewidelyheldtosuck है। Fixing this would be difficult on the JVM।.NET/CLR
In contrast to the JVM situation, .NET supports reified generics. क्या Scala's .NET implementation उनका उपयोग करता है? यदि नहीं, तो क्या यह हो सकता है, या फिर क्या समस्याएं कारणों का उपयोग कर सकती हैं?
यह प्रगति पर है, ध्यान से स्केल को तोड़ने के लिए सावधानी से काम नहीं है जेवीएम और .NET के बीच एक अर्थशास्त्र।
मैं स्केला उपकरण मेलिंग सूची पर वापस इस प्रश्न पूछा 2011 में और जवाब मिगुएल गार्सिया जिसमें उन्होंने बड़ी तस्वीर की रूपरेखा द्वारा दिया जाता है:
कुछ उद्धरण:
(1) क्या Scala.Net पूर्वावलोकन वर्तमान में करता है। जैसा कि आपने देखा है, एरर चरण भी पाइपलाइन के हिस्से के रूप में चलता है। यह पूर्वावलोकन संस्करण का "फीचर" है, एक "फीचर" जिसे शामिल किया जाना था क्योंकि सीएलआर जेनेरिक के लिए समर्थन अभी तक नहीं था (नीचे पर अधिक)। हालांकि, Scala.Net में JVM-style मिरर चलाने के लिए एक बड़ा फायदा है: पर भरोसा करने वाले सभी स्कैला प्रोग्राम, सीएलआर जेनरिक के लिए प्रतीक्षा करने के बजाय स्कैला लाइब्रेरी को पहले से ही संकलित किया जा सकता है। जावा जेडीके पर भरोसा करने वाले उन कार्यक्रमों को भी संकलित किया जा सकता है, जो प्रश्न [1] में जेडीके एपीआई के आईकेवीएम समर्थन के अधीन है।
(2) Scala.Net में सीएलआर जेनेरिक के लिए समर्थन। पर मुख्य प्रेरणा यह मौजूदा असेंबली के साथ अंतःक्रियाशीलता प्राप्त कर रही है। में अंतःक्रियाशीलता प्राप्त करने में, स्केल अर्थशास्त्र से को तोड़ने के लिए देखभाल नहीं की जाएगी। दूसरे शब्दों में, कोई वैध स्कैला प्रोग्राम पर जा रहा है ताकि JVM और .NET पर समान परिणाम चलाए जा सकें। जो प्रगति पर काम करने के लिए हमें लाता है [2]। प्रारंभिक प्रोटोटाइप केवल स्केल के सी # उप-समूह को संभालता है। तो अब मैं बाकी को संबोधित कर रहा हूं। यह की तुलना में अधिक काम है, शुरुआत में अनुमानित है लेकिन पूरी भाषा को कवर करना महत्वपूर्ण है।
विशेष देशी मुद्दों में .NET असेंबली के साथ इंटरऑप के संबंध में कुछ और टिप्पणियां। हां, सीएलआर असेंबली "मूल int" (विभिन्न CPUs पर विभिन्न आकार) का उपयोग करके व्यक्त कर सकते हैं, पी/ सी/फ़ंक्शन द्वारा निर्यात किए गए सी-फ़ंक्शंस। Scala.Net को कम-स्तरीय चालबाजी करने का लक्ष्य नहीं रखता है। "सामान्य भाषा विशिष्टता" के स्तर पर ब्याज की असेंबली इंटरऑपरेबिलिटी है, यानी सामान्यतः किसी भी सी #, वीबी.नेट, आदि कंपाइलर से प्राप्त होता है ("सामान्यतः" यानी "[DllImport]" विशेषताओं और संबंधित सी ++ - isms)।
CLI कल्पना से हवाला देते हुए:
--- उद्धरण शुरू --- आम भाषा विशिष्टता (सीएलएस) - सीएलएस भाषा डिजाइनरों और ढांचे के बीच एक समझौता है डिजाइनरों (अर्थात, वर्ग पुस्तकालय है) । यह सीटीएस (सामान्य टाइप सिस्टम) का एक सबसेट निर्दिष्ट करता है और उपयोग सम्मेलनों का एक सेट निर्दिष्ट करता है। भाषाएं सीएलएस के कम से कम उन हिस्सों को लागू करके ढांचे तक पहुंचने के लिए अपने उपयोगकर्ताओं को सबसे बड़ी क्षमता प्रदान करती हैं जो सीएलएस के भाग हैं। इसी तरह, उनके सार्वजनिक रूप से निर्यात किए गए पहलुओं (उदाहरण के लिए, कक्षाएं, इंटरफेस, विधियां, और फ़ील्ड) केवल सीएलएस का हिस्सा हैं और सीएलएस सम्मेलनों का का पालन करते हैं, तो ढांचे का व्यापक रूप से उपयोग किया जाएगा। --- अंत बोली ---
पूरे थ्रेड के लिए देखें:
https://groups.google.com/forum/?fromgroups#!topic/scala-tools/JDjstK1_uvM
this question के उत्तर से, आप यह ले सकते हैं कि वीएम में संरक्षित जेनेरिक होने के लिए यह कोई फायदा नहीं हो सकता है, क्योंकि यह अभी भी निर्देशित करेगा कि किस प्रकार का प्रतिनिधित्व किया जा सकता है और प्रकारों के बीच संबंध क्या हैं। (अधिक जानकारी के लिए, ओला बिनी द्वारा original blog पर जाएं)।
अन्य उदाहरण:
मिटाना उपयोगी ही नहीं, पीछे की ओर-संगतता के लिए लगता है, लेकिन क्योंकि पूरा क्रम गतिशील रूप से टाइप की गई भाषाओं द्वारा प्रचारित प्रकार की जानकारी लागत पर आती है। .NET CLR जेनेरिक का डिज़ाइन कोड विशेषज्ञता द्वारा इस लागत को निपटाता है। उपरोक्त मामलों को मिटा दिया जाना चाहिए जब यह मिटाना है और जब यह ऐसी भाषा है जिसे किसी विशेष कमी के लिए दोषी ठहराया जाना चाहिए।
शुद्ध शुद्ध है कि अगर JVM जेनरिक reified था (कोई प्रकार विलोपन), यह संभव नहीं स्काला के प्रकार प्रणाली को लागू करने के लिए होगा है ... स्काला के प्रकार प्रणाली की तुलना में अधिक जटिल है जावा के और यदि जेवीएम में जावा जेनरिक पर आधारित जेनेरिक थे, तो हमें अभी भी स्कैला में समस्याएं होंगी। दूसरी ओर, टाइप एरर संकलक को एक जटिल प्रकार प्रणाली को लागू करने की अनुमति देता है, भले ही सभी प्रकार की जानकारी रनटाइम पर उपलब्ध न हो।
जहाँ तक मुझे पता के रूप में स्काला का नेट बैकएंड का समर्थन नहीं करता नेट जेनरिक reified है अब तक वर्तमान JVM कार्यान्वयन पीछे है, और भी।
स्काला 2.10 यहां तक कि वास्तविक आभासी मशीन मॉडल से प्रकार की जानकारी सार संक्षेप की दिशा में चला जाता है आगे। मार्टिन ओडर्स्की ने एक प्रेजेंटेशन में नया प्रतिबिंब/संशोधन इंटरैक्शन प्रस्तुत किया जो उदाहरण के लिए embedded in this entry (42'18 "से शुरू होता है)
मेरा मानना है कि आप फिर टाइप-टैग (जो प्रकट होते हैं) का उपयोग करने में सक्षम होंगे पैटर्न मिलान और मिटाने के साथ समस्याओं को दूर करें। this mailing list thread पर थोड़ा सा है, लेकिन मुझे नहीं पता कि यह कितना हद तक काम करता है या नहीं।
(शुद्ध अटकलें :) अधिक अमूर्तता के लिए जाकर बैकएंड के लिए मदद मिल सकती है प्लेटफार्म जिनके पास JVM की तुलना में कम प्रकार की जानकारी है, उदाहरण के लिए जावास्क्रिप्ट को एक काल्पनिक संकलन।
एम गार्सिया एक संबंधित [लेख] है (http://lampwww.epfl.ch/~ magarcia/ScalaNET/स्लाइड/TourCLRGenerics।पीडीएफ) और [स्टेटस अपडेट] (http://lampwww.epfl.ch/~magarcia/ScalaNET/slides/2011-09-06-GenericsGettingCloser.pdf)। लेकिन कार्यान्वयन के विवरण के साथ इन सौदा; बड़ी तस्वीर प्राप्त करना मुश्किल है। –