2010-03-29 11 views
8

बस एक विचार।सी # 5.0 में वैकल्पिक जेनेरिक प्रकार पैरामीटर के बारे में क्या?

क्या सी # में वैकल्पिक प्रकार पैरामीटर होना उपयोगी नहीं होगा?

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

यह:

interface IEnumerable<out T=object>{ 
    IEnumerator<T> GetEnumerator() 
} 

आप क्या सोचते हैं?

+0

अपने उदाहरण में , आप 'IENumerable ' और 'IENumerable' के बीच अंतर कैसे करेंगे? क्या पहले 'IENumerable <> 'होगा? –

+0

टाइपऑफ (आईनेमरेबल ) == टाइपऑफ (आईनेमरेबल) == टाइपऑफ (आईनेमरेबल <>)। मेकजेनेरिकऑर्सो (टाइपऑफ (ऑब्जेक्ट)) –

+0

फ़ाइल नाम की समस्या के लिए यहां मानक समाधान, और मुझे लगता है कि वीएस टीम द्वारा स्वीकृत एक (हालांकि मुझे इस समय एक लिंक नहीं मिल रहा है), AGenericType के लिए फ़ाइल को AGenericType'4.cs जैसे नाम से सहेजना है। –

उत्तर

3

मैं निश्चित रूप से इसके लिए हूं।

मैं वर्तमान में विभिन्न परिदृश्यों के लिए सहायक तरीके लिख रहा हूं जहां मैं विभिन्न सदस्यों और कक्षाओं के तरीकों के संदर्भों को पारित करना चाहता हूं। इसे पूरा करने के लिए, उदाहरण के लिए, एक Expression<Func<TIn, TOut>> सहायक के लिए तर्क के रूप में ले रहा है (जो मुझे लैम्ब्डा अभिव्यक्ति के साथ विधि तक पहुंचने देता है, इस प्रकार सब कुछ दृढ़ता से टाइप किया जाता है)।

लेकिन मुझे वर्तमान में इनपुट तर्कों की प्रत्येक अलग-अलग संख्या के लिए एक नई सहायक विधि परिभाषित करने की आवश्यकता है, क्योंकि मुझे इसके लिए सामान्य तर्कों की एक अलग राशि की आवश्यकता है।

HelperMethod<TIn>(Expression<Action<TIn>> arg) // Yes, C# can distinguish 
HelperMethod<TOut>(Expression<Func<TOut>> arg) // these two from eachother 
HelperMethod<TIn, TOut>(Expression<Func<TIn, TOut>> arg) 
HelperMethod<TIn1, TIn2, TOut>(Expression<Func<TIn1, TIn2, TOut>> arg) 
// etc 

के बजाय मैं, के साथ क्या कर सकता है सबसे, दो तरीकों पर:

HelperMethod<TIn>(Expression<Action<TIn>> arg) 
HelperMethod<TOut, TIn1 = DummyType, ...>(Expression<Func<TIn1, ..., TOut> arg) 

मेरे मामले में, यह कोड दोहराव का एक बहुत से बच जाएंगे ...

2

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

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

मुझे लगता है कि यह डेवलपर को कोई वास्तविक लाभ प्रदान किए बिना भाषा को जटिल करेगा।

+1

यह टाइप हाइर्चरी क्लीनर रखेगा। ए और बी : ए , बी: ए बी

+0

के समान प्रकार से प्राप्त होगा डिफ़ॉल्ट प्रकार सभी बाधाओं के अधीन होगा ताकि बाद वाला कोड अज्ञानी रह सके। यह मूल रूप से IENumerable जैसा होगा INumerable (उदाहरण के तौर पर, सुविधा की असली उपयोगिता अधिक जटिल वास्तुकला के साथ आता है) –

0

यह मुझे स्पष्ट नहीं है कि आप वास्तव में क्या प्रस्तावित कर रहे हैं। वर्तमान में एक ही नाम के साथ प्रकार हो सकते हैं लेकिन विभिन्न प्रकार के पैरामीटर, लेकिन जो विरासत से किसी भी तरह से संबंधित नहीं हैं - तब आपका प्रस्ताव क्या होगा?

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

0

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

यह कहना अच्छा होगा कि मेरा टाइप पैरामीटर टीबी टीए को डिफॉल्ट किया गया है, और टीबीसीएचल्ड टीएसीएचल्ड को डिफॉल्ट किया गया है।

ध्यान दें कि यह एक ऐसी स्थिति थी जिसमें टाइप पैरामीटर लिखना आवश्यक था, क्योंकि अनुमान काम नहीं करेगा।

संबंधित मुद्दे