मैंने आज एक ट्वीट पढ़ा जिसमें कहा गया था:
जावा उपयोगकर्ता टाइप इरेज़र के बारे में शिकायत करते हैं तो यह मज़ेदार होता है, जो कि जावा की सही बात है, जबकि सभी चीजों को अनदेखा करना गलत है।
इस प्रकार मेरा प्रश्न है:
क्या जावा के प्रकार के क्षरण से लाभ हैं? बैकवर्ड कम्पैटिबिलिटी और रनटाइम परफॉर्मेंस के लिए जेवीएम इंप्लीमेंटेशन प्रेफरेंस के अलावा अन्य क्या तकनीकी या प्रोग्रामिंग स्टाइल इसका लाभ उठाती है (संभवतः)?
जवाबों:
इस प्रकार के बहुत से उत्तर ट्विटर उपयोगकर्ता के साथ बहुत अधिक चिंतित हैं। यह संदेशों पर ध्यान केंद्रित रखने में मददगार है न कि संदेशवाहक। इस प्रकार अभी तक उल्लिखित अंशों के साथ एक सुसंगत संदेश है:
जावा उपयोगकर्ता टाइप इरेज़र के बारे में शिकायत करते हैं तो यह मज़ेदार होता है, जो कि जावा की सही बात है, जबकि सभी चीजों को अनदेखा करना गलत है।
मुझे भारी लाभ (जैसे परोपकार) और शून्य लागत (कथित लागत कल्पना की सीमा है) मिलती है।
new T एक टूटा हुआ प्रोग्राम है। यह "सभी प्रस्ताव सत्य हैं" दावे के लिए समसामयिक है। मैं इसमें बड़ा नहीं हूं।
ये ट्वीट एक ऐसे परिप्रेक्ष्य को दर्शाते हैं जो इस बात में दिलचस्पी नहीं रखता है कि क्या हम मशीन को कुछ कर सकते हैं , लेकिन इससे अधिक कि क्या हम यह तर्क दे सकते हैं कि मशीन कुछ ऐसा करेगी जो हम वास्तव में चाहते हैं। अच्छा तर्क एक प्रमाण है। सबूत औपचारिक संकेतन या कुछ कम औपचारिक में निर्दिष्ट किए जा सकते हैं। विनिर्देश भाषा के बावजूद, उन्हें स्पष्ट और कठोर होना चाहिए। अनौपचारिक विशिष्टताओं को सही ढंग से संरचना करना असंभव नहीं है, लेकिन अक्सर व्यावहारिक प्रोग्रामिंग में दोषपूर्ण हैं। अनौपचारिक तर्क के साथ हमारे पास जो समस्याएँ हैं उनके लिए हम स्वचालित और खोजपूर्ण परीक्षणों जैसे उपचारों को समाप्त करते हैं। यह कहना नहीं है कि परीक्षण आंतरिक रूप से एक बुरा विचार है, लेकिन उद्धृत ट्विटर उपयोगकर्ता सुझाव दे रहा है कि बहुत बेहतर तरीका है।
इसलिए हमारा लक्ष्य सही कार्यक्रम है जिसे हम स्पष्ट रूप से और कठोरता से इस तरह से समझ सकते हैं कि मशीन वास्तव में कार्यक्रम को कैसे निष्पादित करेगी। हालांकि, यह एकमात्र लक्ष्य नहीं है। हम यह भी चाहते हैं कि हमारे तर्क में अभिव्यक्ति की डिग्री हो। उदाहरण के लिए, केवल इतना ही है कि हम प्रस्ताव तर्क के साथ व्यक्त कर सकते हैं। पहले-क्रम के तर्क जैसे कुछ से सार्वभौमिक (∀) और अस्तित्वगत (quant) मात्रा का ठहराव होना अच्छा है।
इन लक्ष्यों को बहुत अच्छी तरह से टाइप सिस्टम द्वारा संबोधित किया जा सकता है। करी-हावर्ड पत्राचार के कारण यह विशेष रूप से स्पष्ट है । इस पत्राचार को अक्सर निम्नलिखित सादृश्य के साथ व्यक्त किया जाता है: प्रकार कार्यक्रमों के होते हैं जैसे प्रमेय प्रमाण होते हैं।
यह पत्राचार कुछ गहरा है। हम तार्किक अभिव्यक्तियाँ ले सकते हैं, और उन्हें पत्राचार के माध्यम से प्रकारों में अनुवाद कर सकते हैं। फिर यदि हमारे पास एक ही प्रकार के हस्ताक्षर के साथ एक कार्यक्रम है जो संकलित करता है, तो हमने साबित कर दिया है कि तार्किक अभिव्यक्ति सार्वभौमिक रूप से सच है (एक तनातनी)। ऐसा इसलिए है क्योंकि पत्राचार दो तरफा है। प्रकार / कार्यक्रम और प्रमेय / प्रूफ दुनिया के बीच परिवर्तन यांत्रिक हैं, और कई मामलों में स्वचालित हो सकते हैं।
करी-हावर्ड एक कार्यक्रम के लिए विनिर्देशों के साथ क्या करना चाहते हैं में अच्छी तरह से निभाता है।
यहां तक कि करी-हावर्ड की समझ के साथ, कुछ लोगों को एक प्रकार की प्रणाली के मूल्य को खारिज करना आसान लगता है, जब यह
पहले बिंदु के बारे में, शायद IDEs जावा के प्रकार की प्रणाली को आसान बनाते हैं (जो कि अत्यधिक व्यक्तिपरक है)।
दूसरे बिंदु के संबंध में, जावा लगभग होता है पहले-क्रम के तर्क के अनुरूप । जेनरिक सार्वभौमिक परिमाणीकरण के बराबर प्रणाली का उपयोग करते हैं। दुर्भाग्य से, वाइल्डकार्ड केवल अस्तित्वगत मात्रा का एक छोटा सा हिस्सा देते हैं। लेकिन सार्वभौमिक मात्रा का ठहराव बहुत अच्छी शुरुआत है। यह कहने में सक्षम होना अच्छा है कि सभी संभावित सूचियों के List<A>लिए सार्वभौमिक रूप से काम करने के लिए फ़ंक्शन क्योंकि ए पूरी तरह से असंबंधित है। इसके कारण ट्विटर उपयोगकर्ता "समरूपता" के संबंध में बात कर रहा है।
परोपकार के बारे में अक्सर उद्धृत पेपर फिलिप वाडलर की प्रमेय है! । इस पत्र के बारे में जो दिलचस्प है वह यह है कि केवल एक प्रकार के हस्ताक्षर से, हम कुछ बहुत ही दिलचस्प आक्रमणकारियों को साबित कर सकते हैं। अगर हम इन आक्रमणकारियों के लिए स्वचालित परीक्षण लिखेंगे तो हम अपना बहुत समय बर्बाद करेंगे। उदाहरण के लिए, के लिएList<A> अकेले हस्ताक्षर के लिएflatten
<A> List<A> flatten(List<List<A>> nestedLists);हम इसका कारण बन सकते हैं
flatten(nestedList.map(l -> l.map(any_function)))
≡ flatten(nestList).map(any_function)यह एक सरल उदाहरण है, और आप शायद इसके बारे में अनौपचारिक रूप से कारण कर सकते हैं, लेकिन यह भी अच्छा है जब हमें इस तरह के सबूत औपचारिक रूप से टाइप सिस्टम से मुफ्त में मिलते हैं और संकलक द्वारा जांच की जाती है।
भाषा के कार्यान्वयन के दृष्टिकोण से, जावा के जेनेरिक (जो सार्वभौमिक प्रकार के अनुरूप हैं) हमारे कार्यक्रम क्या करते हैं, इसके बारे में प्रमाण प्राप्त करने के लिए उपयोग की जाने वाली पारमार्थिकता में बहुत भारी भूमिका निभाते हैं। यह बताई गई तीसरी समस्या के लिए हो जाता है। सबूत और शुद्धता के इन सभी लाभों के लिए दोषों के बिना कार्यान्वित ध्वनि प्रकार की प्रणाली की आवश्यकता होती है। जावा में निश्चित रूप से कुछ भाषा विशेषताएं हैं जो हमें हमारे तर्क को चकनाचूर करने की अनुमति देती हैं। इनमें शामिल हैं, लेकिन इन तक सीमित नहीं हैं:
गैर-मिटाया गया जेनेरिक कई तरीकों से संबंधित है। बिना मिटाए रनटाइम की जानकारी है जो कि कार्यान्वयन के साथ होती है जिसे हम अपने एल्गोरिदम को डिजाइन करने के लिए उपयोग कर सकते हैं। इसका मतलब यह है कि सांख्यिकीय रूप से, जब हम कार्यक्रमों के बारे में तर्क देते हैं, तो हमारे पास पूरी तस्वीर नहीं होती है। परावर्तन गंभीर रूप से किसी भी प्रमाण की शुद्धता की धमकी देता है जो हम सांख्यिकीय रूप से करते हैं। यह कोई संयोग प्रतिबिंब नहीं है जो कई प्रकार के पेचीदा दोषों की ओर ले जाता है।
तो ऐसे कौन से तरीके हैं जो गैर-मिटे हुए जेनरिक "उपयोगी" हो सकते हैं? आइए ट्वीट में वर्णित उपयोग पर विचार करें:
<T> T broken { return new T(); }यदि T के पास कोई arg निर्माता नहीं है तो क्या होगा? कुछ भाषाओं में आपको जो मिलता है वह शून्य है। या शायद आप अशक्त मूल्य को छोड़ देते हैं और एक अपवाद को बढ़ाने के लिए सीधे जाते हैं (जो कि शून्य मान वैसे भी नेतृत्व करते हैं)। क्योंकि हमारी भाषा ट्यूरिंग पूर्ण है, इस कारण से यह असंभव है कि किन कॉलों brokenमें "सुरक्षित" प्रकार शामिल होंगे जिनमें कोई भी अर्ग निर्माणकर्ता नहीं होगा और जो नहीं होंगे। हमने यह निश्चितता खो दी है कि हमारा कार्यक्रम सार्वभौमिक रूप से काम करता है।
इसलिए अगर हम अपने कार्यक्रमों के बारे में तर्क करना चाहते हैं, तो हमें दृढ़ता से सलाह दी जाती है कि हम उन भाषा विशेषताओं को न लें, जो हमारे तर्क को धमकी देती हैं। एक बार जब हम ऐसा कर लेते हैं, तो फिर रनटाइम के प्रकार क्यों नहीं छोड़ते? उनकी जरूरत नहीं है। हम इस संतुष्टि के साथ कुछ दक्षता और सरलता प्राप्त कर सकते हैं कि कोई भी जाति विफल नहीं होगी या यह तरीका आह्वान पर गायब हो सकता है।
मिटा देने से तर्क को बढ़ावा मिलता है।
प्रकार एक निर्माण कार्य हैं जो प्रोग्राम को लिखने के लिए उपयोग किए जाते हैं जो कंपाइलर को प्रोग्राम की शुद्धता की जांच करने की अनुमति देता है। एक प्रकार एक मूल्य पर एक प्रस्ताव है - संकलक सत्यापित करता है कि यह प्रस्ताव सत्य है।
एक कार्यक्रम के निष्पादन के दौरान, टाइप जानकारी की कोई आवश्यकता नहीं होनी चाहिए - यह पहले से ही संकलक द्वारा सत्यापित किया गया है। संकलक को कोड पर अनुकूलन करने के लिए इस जानकारी को छोड़ने के लिए स्वतंत्र होना चाहिए - इसे तेजी से चलाएं, एक छोटा बाइनरी उत्पन्न करें आदि प्रकार के मापदंडों की त्रुटि यह सुविधा प्रदान करती है।
जावा रन-टाइम, परावर्तन, इंस्टोफ़ इत्यादि प्रकार की सूचनाओं की अनुमति देकर स्थैतिक टाइपिंग को तोड़ देता है। यह आपको उन कार्यक्रमों का निर्माण करने की अनुमति देता है, जिन्हें वैधानिक रूप से सत्यापित नहीं किया जा सकता है - वे टाइप सिस्टम को बायपास करते हैं। यह स्थिर अनुकूलन के अवसरों को भी याद करता है।
तथ्य यह है कि प्रकार के मापदंडों को मिटा दिया जाता है, इन गलत कार्यक्रमों के कुछ उदाहरणों का निर्माण करने से रोकता है, हालांकि, अधिक गलत जानकारी को रोक दिया जाएगा यदि अधिक प्रकार की जानकारी को मिटा दिया गया था और प्रतिबिंब और इंस्टोफ़ सुविधाओं को हटा दिया गया था।
डेटा प्रकार की "पैरामेट्रिकिटी" की संपत्ति को बनाए रखने के लिए इरेज़र महत्वपूर्ण है। मान लें कि मेरे पास एक प्रकार "सूची" है जो घटक प्रकार T. यानी सूची <T> से अधिक है। यह एक प्रकार का प्रस्ताव है कि यह सूची प्रकार किसी भी प्रकार के लिए कार्य करता है T. तथ्य यह है कि T एक सार है, अबाधित प्रकार पैरामीटर का अर्थ है कि हम इस प्रकार के बारे में कुछ नहीं जानते हैं, इसलिए T के विशेष मामलों के लिए कुछ भी विशेष करने से रोका जाता है।
उदाहरण के लिए, मेरे पास सूची x = asList ("3") है। मैं एक तत्व जोड़ता हूं: xs.add ("q")। मैं ["3", "क्ष"] के साथ समाप्त होता हूं। चूंकि यह पैरामीट्रिक है, इसलिए मैं मान सकता हूं कि सूची x = asList (7); xs.add (8) का अंत [7,8] मैं इस प्रकार से जानता हूं कि यह स्ट्रिंग के लिए एक काम नहीं करता है और इंट के लिए एक चीज है।
इसके अलावा, मुझे पता है कि List.add फ़ंक्शन पतली हवा से टी के मूल्यों का आविष्कार नहीं कर सकता है। मुझे पता है कि यदि मेरे asList ("3") में "7" जोड़ा गया है, तो केवल संभावित उत्तर का निर्माण "3" और "7" मूल्यों से किया जाएगा। सूची में "2" या "z" जोड़े जाने की कोई संभावना नहीं है क्योंकि फ़ंक्शन इसका निर्माण करने में असमर्थ होगा। इनमें से किसी भी अन्य मूल्य को जोड़ने के लिए समझदार नहीं होगा, और पैरामीट्रिकिटी इन गलत कार्यक्रमों को निर्माण से रोकता है।
मूल रूप से, उन्मूलन, पैरामीट्रिकिटी के उल्लंघन के कुछ साधनों को रोकता है, इस प्रकार गलत कार्यक्रमों की संभावनाओं को समाप्त करता है, जो स्थैतिक टाइपिंग का लक्ष्य है।
(हालांकि मैंने पहले से ही यहां एक उत्तर लिखा था, दो साल बाद इस सवाल पर फिर से विचार करते हुए मुझे पता चला कि इसका जवाब देने का एक और तरीका है, इसलिए मैं पिछले उत्तर को बरकरार रख रहा हूं और इसे जोड़ रहा हूं।)
यह अत्यधिक तर्कपूर्ण है कि क्या जावा जेनरिक पर की गई प्रक्रिया "टाइप इरेज़र" नाम की हकदार है। चूंकि जेनेरिक प्रकार मिटाए नहीं जाते हैं लेकिन उनके कच्चे समकक्षों के साथ प्रतिस्थापित किया जाता है, इसलिए बेहतर विकल्प "टाइप म्यूटिलेशन" लगता है।
आमतौर पर समझ में आने वाले प्रकार के क्षरण की विशिष्ट विशेषता स्थैतिक प्रकार प्रणाली की सीमाओं के भीतर रहने के लिए रनटाइम के लिए मजबूर कर रही है, इसे डेटा की संरचना तक "अंधा" बना देती है। यह संकलक को पूरी शक्ति देता है और इसे केवल स्थैतिक प्रकारों के आधार पर प्रमेय साबित करने की अनुमति देता है। यह प्रोग्रामर की स्वतंत्रता की कोड की सीमाओं को बाधित करके, साधारण तर्क को अधिक शक्ति प्रदान करने में भी मदद करता है।
जावा के प्रकार के क्षरण को प्राप्त नहीं होता है - यह संकलक को अपंग करता है, जैसे इस उदाहरण में:
void doStuff(List<Integer> collection) {
}
void doStuff(List<String> collection) // ERROR: a method cannot have
// overloads which only differ in type parameters(उपर्युक्त दो घोषणाएँ एक ही विधि हस्ताक्षर में मिटने के बाद गिर जाती हैं।)
दूसरी तरफ, रनटाइम अभी भी किसी वस्तु के प्रकार और उसके बारे में कारण का निरीक्षण कर सकता है, लेकिन चूंकि सत्य प्रकार में इसकी अंतर्दृष्टि मिटने से अपंग हो जाती है, स्थिर प्रकार के उल्लंघन को प्राप्त करने और रोकने के लिए कठिन हैं।
चीजों को और अधिक जटिल बनाने के लिए, मूल और मिटाए गए प्रकार के हस्ताक्षर सह-अस्तित्व में हैं और संकलन के दौरान समानांतर में माना जाता है। ऐसा इसलिए है क्योंकि पूरी प्रक्रिया रनटाइम से प्रकार की जानकारी को हटाने के बारे में नहीं है, लेकिन पीछे की संगतता बनाए रखने के लिए एक विरासत प्रकार की प्रणाली में जेनेरिक प्रकार प्रणाली को जूता करने के बारे में है। यह रत्न एक उत्कृष्ट उदाहरण है:
public static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll)( extends Objectमिटाए गए हस्ताक्षर की पिछड़ी संगतता को संरक्षित करने के लिए निरर्थक जोड़ा जाना था।)
अब, इस बात को ध्यान में रखते हुए, आइए हम इस उद्धरण पर दोबारा गौर करें:
जावा उपयोगकर्ता टाइप इरेज़र के बारे में शिकायत करते हैं तो यह मज़ेदार है, जो कि जावा सही है
क्या वास्तव में जावा सही मिला? क्या यह अर्थ की परवाह किए बिना स्वयं ही शब्द है? इसके विपरीत विनम्र intप्रकार पर एक नज़र डालें : कोई रनटाइम प्रकार की जाँच कभी भी, या संभव भी नहीं होती है, और निष्पादन हमेशा पूरी तरह से सुरक्षित होता है। यह सही होने पर किस प्रकार का क्षरण दिखता है: आप यह भी नहीं जानते कि यह वहाँ है।
एक बात जो मैं यहाँ बिल्कुल नहीं देखता हूँ वह यह है कि OOP का रनटाइम बहुरूपता मूल रूप से रनटाइम के प्रकारों के पुनरावर्तन पर निर्भर है। जब एक भाषा जिसकी रीढ़ की हड्डी को परिष्कृत प्रकारों से रखा जाता है, वह अपने प्रकार प्रणाली के लिए एक प्रमुख विस्तार का परिचय देती है और इसे प्रकार के क्षरण पर आधारित करती है, संज्ञानात्मक असंगति अपरिहार्य परिणाम है। जावा समुदाय के साथ ठीक यही हुआ है; यही कारण है कि प्रकार के क्षरण ने इतने विवाद को आकर्षित किया है, और अंततः जावा के भविष्य के रिलीज में इसे पूर्ववत करने की योजना क्यों है । जावा उपयोगकर्ताओं की उस शिकायत में कुछ अजीब पाया जाना या तो जावा की भावना की एक ईमानदार गलतफहमी, या एक सचेत रूप से मजाक मजाक में धोखा देता है।
"इरेज़र एकमात्र चीज़ है जिसे जावा ने सही पाया है" इस दावे का तात्पर्य है कि "रनटाइम प्रकार के फ़ंक्शन तर्क के विरुद्ध गतिशील प्रेषण पर आधारित सभी भाषाएँ मौलिक रूप से त्रुटिपूर्ण हैं"। यद्यपि निश्चित रूप से अपने आप में एक वैध दावा है, और एक जिसे जावा सहित सभी ओओपी भाषाओं की वैध आलोचना के रूप में भी माना जा सकता है, यह स्वयं को एक महत्वपूर्ण बिंदु के रूप में प्रस्तुत नहीं कर सकता है जहां से जावा के संदर्भ में सुविधाओं का मूल्यांकन और आलोचना करना है , जहां बहुरूपतावाद है। स्वयंसिद्ध है।
सारांश में, जबकि कोई व्यक्ति "भाषा के डिजाइन में जाने का तरीका" कह सकता है, जावा के भीतर टाइप इरेज़र का समर्थन गलत तरीके से किया जाता है, क्योंकि यह बहुत अधिक है, इसके लिए बहुत देर हो चुकी है और पहले से ही ऐतिहासिक क्षण में भी था। जब ओक को सूर्य ने गले लगाया और जावा का नाम दिया गया।
जैसे कि स्टैटिक टाइपिंग ही प्रोग्रामिंग लैंग्वेज के डिजाइन में उचित दिशा है, यह एक व्यापक व्यापक दार्शनिक संदर्भ में फिट बैठता है जो हम सोचते हैं कि यह प्रोग्रामिंग की गतिविधि का गठन करता है । गणित की शास्त्रीय परंपरा से स्पष्ट रूप से व्युत्पन्न एक स्कूल, कार्यक्रमों को एक गणितीय अवधारणा या अन्य (प्रस्ताव, कार्य आदि) के उदाहरणों के रूप में देखता है, लेकिन दृष्टिकोणों की एक पूरी तरह से अलग श्रेणी है, जो प्रोग्रामिंग को एक तरह से देखते हैं मशीन से बात करें और समझाएं कि हम इससे क्या चाहते हैं। इस दृष्टि से यह कार्यक्रम एक गतिशील, व्यवस्थित रूप से विकसित होने वाली इकाई है, एक सांख्यिकीय टाइप किए गए कार्यक्रम के सावधानीपूर्वक बनाए गए एडीड के विपरीत एक नाटकीय।
उस दिशा में एक कदम होने के रूप में गतिशील भाषाओं के संबंध में यह स्वाभाविक प्रतीत होगा: कार्यक्रम की स्थिरता नीचे से ऊपर उठती है , जिसमें कोई प्राथमिकता वाले अवरोधक नहीं होते हैं जो इसे शीर्ष-डाउन तरीके से लागू करेंगे। इस प्रतिमान को एक प्रक्रिया के रूप में देखा जा सकता है, जिसमें प्रक्रिया के माध्यम से हम, मनुष्य, वह बन जाते हैं जो हम विकास और सीखने के माध्यम से करते हैं।
एक ही वार्तालाप में एक ही उपयोगकर्ता द्वारा एक बाद की पोस्ट:
new T एक टूटा हुआ प्रोग्राम है। यह दावा करने के लिए isomorphic है "सभी प्रस्ताव सत्य हैं।" मैं इसमें बड़ा नहीं हूं।
(यह एक अन्य उपयोगकर्ता के एक बयान के जवाब में था, अर्थात् "यह कुछ स्थितियों में लगता है कि 'नया टी' बेहतर होगा", विचार यह new T()है कि प्रकार के क्षरण के कारण असंभव है। (यह बहस योग्य है - भले ही Tउपलब्ध थे। रनटाइम, यह एक अमूर्त वर्ग या इंटरफ़ेस हो सकता है Void, या यह हो सकता है , या इसमें एक नो-आर्ग कंस्ट्रक्टर की कमी हो सकती है, या इसका नो-अर्ग कंस्ट्रक्टर निजी हो सकता है (जैसे, क्योंकि यह एक सिंगलटन वर्ग होना चाहिए), या इसका नो-आर्ग कंस्ट्रक्टर एक चेक किए गए अपवाद को निर्दिष्ट कर सकता है जो सामान्य विधि को पकड़ या निर्दिष्ट नहीं करता है - लेकिन वह आधार था। भले ही, यह सच है कि बिना मिटाए आप कम से कम लिख सकते हैं T.class.newInstance(), जो उन मुद्दों को संभालता है।)।
यह विचार, उस प्रकार के प्रस्ताव के लिए समसामयिक हैं, यह दर्शाता है कि उपयोगकर्ता के पास औपचारिक प्रकार के सिद्धांत में एक पृष्ठभूमि है। (एस) वह बहुत "गतिशील प्रकार" या "रनटाइम-प्रकार" पसंद नहीं instanceofकरता है और डाउनकास्ट और प्रतिबिंब और इतने पर बिना जावा को पसंद करेगा । (मानक एमएल जैसी भाषा के बारे में सोचें, जिसके पास बहुत समृद्ध (स्थिर) प्रकार की प्रणाली है और जिसका गतिशील शब्दार्थ किसी भी प्रकार की जानकारी पर निर्भर नहीं करता है।)
यह ध्यान में रखने योग्य है, वैसे, उपयोगकर्ता ट्रोलिंग कर रहा है: जबकि (ओं) को वह ईमानदारी से पसंद करते हैं (सांख्यिकीय रूप से) टाइप की गई भाषाएं, (ओं) वह ईमानदारी से उस दृश्य के अन्य लोगों को मनाने की कोशिश नहीं कर रहा है। बल्कि, मूल ट्वीट का मुख्य उद्देश्य उन लोगों का मजाक उड़ाना था जो असहमत थे, और कुछ असहमत लोगों ने इस पर चुटकी ली, उपयोगकर्ता ने फॉलो-अप ट्वीट्स पोस्ट किए जैसे कि "कारण जावा में टाइप इरेज़र है कि वडलर एट अल क्या जानते हैं वे जावा के उपयोगकर्ताओं के विपरीत कर रहे हैं "। दुर्भाग्य से, यह पता लगाना कठिन है कि वह वास्तव में क्या सोच रहा है; लेकिन सौभाग्य से, इसका मतलब यह भी है कि ऐसा करना बहुत महत्वपूर्ण नहीं है। अपने विचार करने के लिए वास्तविक गहराई के साथ लोग आम तौर पर trolls कि कर रहे हैं का सहारा नहीं है काफी इस सामग्री से मुक्त हो।
एक अच्छी बात यह है कि जेनरिक को पेश किए जाने के समय जेवीएम को बदलने की कोई आवश्यकता नहीं थी। जावा कंपाइलर स्तर पर ही जेनरिक लागू करता है।
कारण प्रकार का क्षरण एक अच्छी बात यह है कि जिन चीजों को यह असंभव बनाता है वे हानिकारक हैं। रनटाइम पर टाइप तर्कों के निरीक्षण को रोकना कार्यक्रमों के बारे में समझ और तर्क को आसान बनाता है।
एक अवलोकन जो मैंने कुछ प्रति-सहज पाया, वह यह है कि जब फ़ंक्शन हस्ताक्षर अधिक सामान्य होते हैं, तो उन्हें समझना आसान हो जाता है। ऐसा इसलिए है क्योंकि संभावित कार्यान्वयन की संख्या कम हो जाती है। इस हस्ताक्षर के साथ एक विधि पर विचार करें, जिसे हम जानते हैं कि इसका कोई दुष्प्रभाव नहीं है:
public List<Integer> XXX(final List<Integer> l);इस समारोह के संभावित कार्यान्वयन क्या हैं? बहुत सारे। आप इस फ़ंक्शन के बारे में बहुत कम बता सकते हैं। यह इनपुट सूची को उलट सकता है। यह एक साथ चींटियों को बाँध सकता है, उन्हें समेट सकता है और सूची को आधे आकार में लौटा सकता है। कई अन्य संभावनाएं हैं जिनकी कल्पना की जा सकती है। अब विचार करें:
public <T> List<T> XXX(final List<T> l);इस फ़ंक्शन के कितने कार्यान्वयन हैं? चूंकि कार्यान्वयन को तत्वों के प्रकार का पता नहीं चल सकता है, इसलिए कार्यान्वयन की एक बड़ी संख्या को अब बाहर रखा जा सकता है: तत्वों को जोड़ा नहीं जा सकता है, या सूची में जोड़ा जा सकता है या बाहर फ़िल्टर किया जा सकता है, एट अल। हम चीजों तक सीमित हैं: पहचान (सूची में कोई बदलाव नहीं), तत्वों को छोड़ना या सूची को उलट देना। यह फ़ंक्शन अकेले अपने हस्ताक्षर के आधार पर तर्क करना आसान है।
सिवाय ... जावा में आप हमेशा टाइप सिस्टम को धोखा दे सकते हैं। क्योंकि उस सामान्य विधि के क्रियान्वयन से instanceofचेक और / या मनमाने प्रकार के सामानों का उपयोग किया जा सकता है , इस प्रकार के हस्ताक्षर के आधार पर हमारे तर्क आसानी से बेकार हो सकते हैं। फ़ंक्शन तत्वों के प्रकार का निरीक्षण कर सकता है और परिणाम के आधार पर किसी भी संख्या में कर सकता है। यदि इन रनटाइम हैक की अनुमति है, तो पैरामीटर किए गए विधि हस्ताक्षर हमारे लिए बहुत कम उपयोगी हो जाते हैं।
अगर जावा में टाइप इरेज़र नहीं था (यानी रनटाइम में टाइप की गई दलीलें फिर से मिल जाती हैं) तो यह इस तरह के और अधिक तर्क-वितर्क वाले शेंनिगन्स की अनुमति देगा । उपरोक्त उदाहरण में, कार्यान्वयन केवल प्रकार के हस्ताक्षर द्वारा निर्धारित अपेक्षाओं का उल्लंघन कर सकता है यदि सूची में कम से कम एक तत्व है; लेकिन अगर Tयह सही था, तो सूची खाली होने पर भी ऐसा कर सकता था। संशोधित प्रकार कोड की हमारी समझ को बाधित करने के लिए (पहले से ही बहुत) संभावनाओं को बढ़ाएगा।
टाइप इरेज़र भाषा को कम "शक्तिशाली" बनाता है। लेकिन "शक्ति" के कुछ रूप वास्तव में हानिकारक हैं।
instanceofहमारी क्षमता को इस कारण से बाधित करती हैं कि कोड किस प्रकार के आधार पर करता है। यदि जावा प्रकार के तर्कों को संशोधित करने के लिए था, तो यह इस समस्या को और बदतर बना देगा। रनटाइम पर इरेजिंग प्रकारों का प्रभाव टाइप सिस्टम को अधिक उपयोगी बनाने में होता है।
यह एक सीधा जवाब नहीं है (ओपी ने पूछा "क्या फायदे हैं", मैं जवाब दे रहा हूं "क्या विपक्ष हैं")
सी # टाइप सिस्टम की तुलना में, जावा टाइप इरेज़र दो रैसन के लिए एक वास्तविक दर्द है
C # में आप दोनों को IEnumerable<T1>और IEnumerable<T2>सुरक्षित रूप से लागू कर सकते हैं, खासकर यदि दो प्रकार के एक सामान्य पूर्वज (यानी उनका पूर्वज है Object ) को साझा नहीं करते हैं ।
व्यावहारिक उदाहरण: स्प्रिंग फ्रेमवर्क में, आप ApplicationListener<? extends ApplicationEvent>कई बार लागू नहीं कर सकते । यदि आपको Tपरीक्षण के आधार पर विभिन्न व्यवहारों की आवश्यकता हैinstanceof
(और आपको ऐसा करने के लिए कक्षा का संदर्भ चाहिए)
जैसा कि दूसरों ने टिप्पणी की है, के बराबर करना new T()केवल प्रतिबिंब के माध्यम से किया जा सकता है, केवल एक उदाहरण को लागू Class<T>करके, निर्माता द्वारा आवश्यक मापदंडों के बारे में सुनिश्चित करना। C # आपको new T() केवल तभी करने की अनुमति देता है जब आप Tपैरामीटररहित कंस्ट्रक्टर को बाध्य करते हैं। यदि Tवह बाधा का सम्मान नहीं करता है, तो एक संकलन त्रुटि उठाई जाती है।
जावा में, आपको अक्सर उन तरीकों को लिखने के लिए मजबूर किया जाएगा जो निम्नलिखित की तरह दिखते हैं
public <T> T create(....params, Class<T> classOfT)
{
... whatever you do
... you will end up
T = classOfT.newInstance();
... or more advanced reflection
Constructor<T> parameterizedConstructorThatYouKnowAbout = classOfT.getConstructor(...,...);
}उपरोक्त कोड में कमियां हैं:
ReflectiveOperationExceptionतो रनटाइम पर फेंक दिया जाता हैयदि मैं C # का लेखक था, तो मैंने एक या एक से अधिक कंस्ट्रक्टर बाधाओं को निर्दिष्ट करने की क्षमता का परिचय दिया होगा जो कि संकलन समय पर सत्यापित करना आसान है (इसलिए मुझे उदाहरण के लिए string,stringपरमर्स के साथ एक कंस्ट्रक्टर की आवश्यकता हो सकती है )। लेकिन आखिरी एक अटकल है
एक अतिरिक्त बिंदु अन्य उत्तरों में से कोई भी नहीं माना गया है: यदि आपको रन-टाइम टाइपिंग के साथ वास्तव में जेनरिक की आवश्यकता है, तो आप इसे इस तरह लागू कर सकते हैं :
public class GenericClass<T>
{
private Class<T> targetClass;
public GenericClass(Class<T> targetClass)
{
this.targetClass = targetClass;
}यह वर्ग तब उन सभी कामों को करने में सक्षम होता है जो जावा द्वारा इरेज़र का उपयोग न करने पर डिफ़ॉल्ट रूप से प्राप्त करने योग्य होगा: यह नई Tएस आवंटित कर सकता है (यह मानते हुए Tकि यह निर्माण करने वाले पैटर्न से मेल खाता है), या एस के सरणियों से मेल खाता है T, यह कर सकता है गतिशील रूप से रन टाइम पर परीक्षण करें यदि कोई विशेष वस्तु एक है Tऔर उसके आधार पर व्यवहार में परिवर्तन होता है, और इसी तरह।
उदाहरण के लिए:
public T newT () {
try {
return targetClass.newInstance();
} catch(/* I forget which exceptions can be thrown here */) { ... }
}
private T value;
/** @throws ClassCastException if object is not a T */
public void setValueFromObject (Object object) {
value = targetClass.cast(object);
}
}सी ++ से बचा जाता है - जैसे कोड ब्लोट क्योंकि एक ही कोड कई प्रकारों के लिए उपयोग किया जाता है; हालाँकि, टाइप इरेज़र के लिए वर्चुअल डिस्पैच की आवश्यकता होती है जबकि c ++ - कोड-ब्लॉट एप्रोच गैर-वस्तुतः प्रचलित जेनेरिक कर सकते हैं
अधिकांश उत्तर वास्तविक तकनीकी विवरण की तुलना में प्रोग्रामिंग दर्शन के बारे में अधिक चिंतित हैं।
और यद्यपि यह प्रश्न 5 वर्ष से अधिक पुराना है, फिर भी यह प्रश्न स्पष्ट है: तकनीकी दृष्टिकोण से टाइप इरेज़र वांछनीय क्यों है? अंत में, इसका उत्तर सरल है (उच्च स्तर पर): https://en.wikipedia.org/wiki/Type_erasure
C ++ टेम्पलेट रनटाइम पर मौजूद नहीं है। संकलक प्रत्येक आह्वान के लिए पूरी तरह से अनुकूलित संस्करण का उत्सर्जन करता है, जिसका अर्थ है कि निष्पादन प्रकार की जानकारी पर निर्भर नहीं करता है। लेकिन एक ही फ़ंक्शन के विभिन्न संस्करणों के साथ एक जेआईटी कैसे निपटता है? यह सिर्फ एक समारोह के लिए बेहतर नहीं होगा? जेआईटी नहीं चाहेगा कि इसके सभी अलग-अलग संस्करणों का अनुकूलन किया जाए। ठीक है, लेकिन फिर प्रकार की सुरक्षा के बारे में क्या? लगता है कि खिड़की से बाहर जाना है।
लेकिन एक सेकंड रुको: .NET यह कैसे करता है? प्रतिबिंब! इस तरह उन्हें केवल एक फ़ंक्शन का अनुकूलन करना होगा और रनटाइम प्रकार की जानकारी भी प्राप्त करनी होगी। और यही कारण है कि .NET जेनेरिक धीमे होते थे (हालांकि वे बहुत बेहतर हो गए हैं)। मैं यह तर्क नहीं दे रहा हूं कि यह सुविधाजनक नहीं है! लेकिन यह महंगा है और इसका उपयोग तब किया जाना चाहिए जब यह बिल्कुल आवश्यक न हो (यह डायनामिक रूप से टाइप की गई भाषाओं में महंगा नहीं माना जाता है क्योंकि कंपाइलर / दुभाषिया किसी भी तरह प्रतिबिंब पर निर्भर करता है)।
इस तरह से टाइप इरेज़र के साथ सामान्य प्रोग्रामिंग जीरो ओवरहेड के करीब है (कुछ रनटाइम चेक / कास्ट अभी भी आवश्यक हैं): https://docs.oracle.com/javase/tutorial/java/generics/erasure.html