आज,
Kyta में एक बहुत ही
दिलचस्प सवाल पूछा गया था कि C # में क्यों
अनुमानित रूप से टाइप किए गए स्थानीय वैरिएबल aka
var हैं , लेकिन कोई अंतर्निहित प्रकार नहीं हैं?
वास्तव में, मामलों की यह स्थिति बिल्कुल आकस्मिक नहीं है; तो आइए कुछ कारणों पर गौर करें कि कंपाइलर इस तरह से व्यवहार करता है और अन्यथा नहीं।
सबसे पहले, स्पष्ट रूप से टाइप किए गए स्थानीय चर घोषित करने के लिए
var का उपयोग करने की क्षमता कभी भी एक स्वतंत्र विशेषता नहीं रही है। C # भाषा का विकास करते समय, कोई भी एक पूर्ण रूप से अंतर्निहित टाइपिंग प्रोग्रामिंग भाषा बनाने का लक्ष्य निर्धारित नहीं करता है, जैसे कि F #; संक्षिप्त टाइपिंग एक अधिक सामान्य अवधारणा का केवल एक घटक (यद्यपि महत्वपूर्ण) था, जिसे आज संक्षिप्त LINQ के तहत जाना जाता है।
चूंकि LINQ विकसित करते समय, यह तय किया गया था कि केवल एक डेवलपर को मौजूदा प्रकारों से बांधना "एक बुराई" प्रतिबंध था, जब इसे लागू किया गया था, तो डेवलपर को अनाम कक्षाओं के अनुक्रम वापस करने का अवसर दिया गया था। और यदि ऐसा है, तो निहित टाइप किए गए चर के उपयोग के बिना यह संभव नहीं होगा:
IEnumerable <Customer> customers = null ;
// , result ? IEnumerable<??>?
var result = from c in customers
where c.Age > 33
select new {c.Name, c.Age};
* This source code was highlighted with Source Code Highlighter .
हालांकि, एक प्रकार की घोषणा में
var कीवर्ड का उपयोग अधिक वैश्विक लक्ष्य को हल करने में मदद नहीं करेगा (यह LINQ के बारे में फिर से है)।
दूसरे, भले ही एक अवसर के लिए कंपाइलर (*) के लिए यह कितना मुश्किल होगा, यह पता नहीं है, इसके कार्यान्वयन और उपयोग से जुड़े कुछ नुकसान भी हैं। पहली कमी यह है कि अनुमानित प्रकार के फ़ील्ड गुमनाम प्रकार के साथ बुरे दोस्त होंगे।
आइए निम्न वर्ग की कल्पना करें:
public class Foo
{
public var someField = new {Name = "name" , Value = 12};
}
* This source code was highlighted with Source Code Highlighter .
चूंकि .Net में अनाम प्रकार अब आंतरिक प्रकारों के रूप में कार्यान्वित किए जाते हैं, इसलिए वर्तमान विधानसभा के बाहर इस प्रकार का "निर्यात" करना असंभव है। आप निश्चित रूप से केवल आंतरिक या निजी क्षेत्रों के लिए वर्ग टाइप के निहित क्षेत्रों के उपयोग को प्रतिबंधित कर सकते हैं, या यहां तक कि अनाम वर्ग के साथ अंतर्निहित टाइप किए गए क्षेत्रों के उपयोग को भी प्रतिबंधित कर सकते हैं, लेकिन यह दो शब्दार्थ समान सी / भाषा के निर्माण को भी अलग बना देगा। C # 3.0 में
दिखाई देने वाले कारणों में से एक गुमनाम प्रकार (LINQ के साथ या बिना) का उपयोग है, और यहाँ यह पता चलता है कि उनके द्वारा अनुमानित रूप से टाइप किए गए फ़ील्ड काम नहीं करेंगे।
एक अन्य महत्वपूर्ण सीमा यह है कि अनुमानित रूप से टाइप किए गए फ़ील्ड प्रारंभिक फ़ील्ड और "इनिशलाइज़र" के बीच एक कनेक्शन को बंद करते हैं। आइए एक उदाहरण देखें: मान लें कि हमारे पास एक वर्ग
ए है जिसमें एक "var" फ़ील्ड शामिल है जिसे
फू कहा जाता है, जिसे क्लास
बी के स्थिर विधि
फू को कॉल करके आरंभ किया जाता है:
public class A
{
public static var foo = B.Foo();
}
public class B
{
public static int Foo()
{
return default ( int );
}
}
* This source code was highlighted with Source Code Highlighter .
इससे कई अतिरिक्त प्रश्न सामने आते हैं: यदि
ए और
बी अलग-अलग विधानसभाओं में स्थित हैं तो क्या होगा? लेकिन क्या होगा अगर असेंबली
ए को फिर से जमा किए बिना
, क्लास
बी के साथ असेंबली को फिर से जोड़ दिया जाए और
फू विधि का रिटर्न प्रकार
इंट से
स्ट्रिंग में बदल जाए ? या हमारे पास अभी भी एक अंतर्निहित टाइप
सी फ़ील्ड है
। फू (यानी, कक्षा
सी में फ़ील्ड
फू ), क्षेत्र के प्रकार के लिए बाध्य
ए। फू , क्षेत्र
डी। फू , क्षेत्र
सी। फू से बंधा हुआ है, आदि। और फिर एक फ़ंक्शन के रिटर्न मान के प्रकार को बदलने से एक दर्जन विभिन्न वर्गों (**) में फ़ील्ड के प्रकार में बदलाव होगा। वैसे भी, फ़ील्ड स्थानीय चर की तुलना में किसी वर्ग के डिज़ाइन और उसके कार्यान्वयन का एक महत्वपूर्ण हिस्सा हैं, इसलिए इस फ़ील्ड की तरह ही फ़्लाई-द-चेंज करना, क्योंकि किसी ने तीसरे मॉड्यूल में फ़ंक्शन सिग्नेचर को बदल दिया है, यह एक अच्छा विचार नहीं है।
बेशक, कोई केवल मामलों के एक सीमित सेट में निहित टाइप किए गए क्षेत्रों का उपयोग करने की संभावना को सीमित कर सकता है, और अन्य विधानसभाओं से अनाम प्रकारों और वर्गों के साथ इस सुविधा के उपयोग पर प्रतिबंध लगा सकता है, और उदाहरण के लिए, केवल वर्तमान वर्ग के तरीकों का उपयोग। लेकिन इस मामले में भी, इस सुविधा के कार्यान्वयन के लिए बहुत अधिक कार्यान्वयन के प्रयास की आवश्यकता है (एरिक का प्रमाण, मुझे जे से कोई लेना-देना नहीं है), जो इसे सुधारने की अंतहीन सूची में कम प्राथमिकता देता है जो सी # कंपाइलर डेवलपर्स के सिर में है।
----------------------
(*) विल्ड्स में जाने का कोई मतलब नहीं है, जैसा कि एरिक लिपर्ट ने अपने लेख में पहले ही कर दिया था
कि खेतों पर कोई संस्करण क्यों नहीं? , जिसमें वह इस तथ्य के बारे में बात करता है कि निहित रूप से टाइप किए गए क्षेत्रों के कार्यान्वयन के लिए अनुमानित रूप से टाइप किए गए स्थानीय चर के कार्यान्वयन की तुलना में अधिक महत्वपूर्ण कार्यान्वयन लागत की आवश्यकता होगी।
(**) बेशक, यह एक संकेतक नहीं है, और सही या गलत तरीके से उपयोग करने का कोई भी अवसर। लेकिन इस चीज़ की मदद से, आप एक को पुरस्कृत कर सकते हैं कि नोट में दिया गया उदाहरण
किसी केस
के लिए कोड न लिखने के रूप में भी फूलों के रूप में प्रकट हो सकता है (चूंकि छोटे परिवर्तन एक वर्ग में नहीं, बल्कि एक दर्जन अन्य लोगों में भी बड़े पैमाने पर पैदा होंगे)।