सामान्य प्रकार पैरामीटर की बाधाओं को परिभाषित करते समय, हमें अंत में class() और new() को अंत में रखना होगा, उदाहरण के लिए।जेनेरिक पैरामीटर बाधाओं में कुछ ऑर्डरिंग क्यों लागू की जाती है?
यह क्यों है, मैं अपनी बाधाओं को किसी भी क्रम में क्यों नहीं डाल सकता?
class/struct पहले, new() के अलावा ऑर्डर करने पर कोई अन्य प्रतिबंध हैं?
उदाहरण:
protected T Clone<T>() where T : class, ICopyable<T>, new()
की कोई खास कारण है कि इसी क्रम में चुना गया था है। चुना गया आदेश अधिक सामान्य से अधिक विशिष्ट तक जाता है, जो मुझे लगता है कि एक उचित अच्छी संपत्ति है।
प्रश्न के लिए "किसी ऑर्डर की आवश्यकता क्यों है?", यह कार्यान्वयन और परीक्षण टीमों पर भाषा द्वारा लगाए गए स्पष्ट, स्पष्ट आदेश के लिए आसान है। हम बाधाओं को किसी भी क्रम में आने की अनुमति दे सकते हैं, लेकिन यह हमें क्या खरीदता है?
जितना अधिक मैं भाषाओं पर काम करता हूं, उतना ही मैं राय मानता हूं कि हर बार जब आप उपयोगकर्ता को कोई विकल्प देते हैं, तो आप उन्हें खराब विकल्प बनाने का मौका देते हैं। सी # का एक बुनियादी डिजाइन सिद्धांत यह है कि जब हम चीजें गलत लगती हैं और आपको सही बनाने के लिए मजबूर करती हैं, तो हम आपको बताते हैं - जो जावास्क्रिप्ट का मूल डिजाइन सिद्धांत नहीं है। इसका मूल डिजाइन सिद्धांत "गड़बड़ी कर रहा है और उपयोगकर्ता का क्या मतलब है" करने का प्रयास करें। सी # में सही वाक्यविन्यास पर अधिक प्रतिबंध लगाकर हम बेहतर ढंग से सुनिश्चित कर सकते हैं कि इच्छित अर्थशास्त्र प्रोग्राम में अच्छी तरह से व्यक्त किया गया है।
class C : X , Y
या
... where T : X, Y
वाई स्पष्ट रूप से करने का इरादा है:
उदाहरण के लिए, अगर मैं आज एक सी # की तरह भाषा को डिजाइन किया गया था कोई रास्ता नहीं है कि मैं की तरह अस्पष्ट वाक्यविन्यास होता है एक इंटरफ़ेस एक्स है? हम सिंटेक्टिक रूप से नहीं बता सकते कि एक्स का उद्देश्य इंटरफ़ेस या क्लास होना था या नहीं। यह अस्पष्टता कहने का पर्याप्त आधार बेस प्रकार बनाम इंटरफेस में चक्रों का पता लगाने जैसी चीजों को बहुत जटिल बनाता है। यह सभी संबंधित लोगों पर अधिक आसान होगा यदि यह अधिक वर्बोज़ था, क्योंकि यह वीबी में है।
+1 समय लेने के लिए धन्यवाद जो कि किए गए निर्णयों के बारे में कुछ अंतर्दृष्टि प्रदान करने के लिए और क्यों। –
मुझे हमेशा यह अजीब लगता है कि सी # विरासत व्यक्त करता है और जावा से अलग इंटरफ़ेस को कार्यान्वित करता है (जो इसे स्पष्ट रूप से करता है), जब सी # अधिकांश अन्य मामलों में जावा द्वारा इतनी भारी प्रभावित होती है। यह और भी अजीब बात है कि जैसा कि आप कहते हैं कि यह संकलक काम को जटिल बनाता है। – MgSam
"कार्यान्वयन और परीक्षण टीमों पर आसान" .. जो मुझे आश्चर्यचकित करता है। हालांकि एक छोटे व्याकरण के कार्यान्वयन शायद थोड़ा आसान है, अब आपके पास कार्यान्वित करने और परीक्षण करने के लिए एक संपूर्ण अतिरिक्त सुविधा है: "आदेश गलत होने पर त्रुटि उत्पन्न करें" –
अधिकांश वाक्यविन्यास संबंधी प्रश्नों की तरह, मूल उत्तर यह है क्योंकि spec ऐसा कहता है। हमें सी # 5.0 spec (धारा 10.1) से सामान्य प्रकार की बाधाओं के लिए निम्न व्याकरण मिलता है।5)
प्रकार पैरामीटर-बाधाओं:
primary-constraint secondary-constraints constructor-constraint primary-constraint , secondary-constraints primary-constraint , constructor-constraint secondary-constraints , constructor-constraint primary-constraint , secondary-constraints , constructor-constraintप्राथमिक-बाधा:
class-type class structमाध्यमिक कमी:
interface-type type-parameter secondary-constraints , interface-type secondary-constraints , type-parameterनिर्माता-बाधा:
new ( )
एरिक Lippert का कारण बताते हुए इसे इस तरह डिजाइन किया गया था का एक बहुत अच्छा काम किया है, तो मैं उस पर व्याख्या नहीं होंगे।
पृष्ठभूमि के रूप में, भाषा विनिर्देश बताता है कि बाधाओं को क्रम में होना चाहिए * प्राथमिक बाधा, माध्यमिक बाधा, कन्स्ट्रक्टर बाधा *, जहां * प्राथमिक बाधा * बस * वर्ग * या * संरचना *, एक * माध्यमिक बाधा है * एक दिया इंटरफ़ेस या कक्षा प्रकार है, और * कन्स्ट्रक्टर बाधा * बस * नया() * है। इसीलिए उन्हें इस तरह वर्गीकृत क्यों किया जाता है और उस आदेश की आवश्यकता होती है, मुझे कोई जानकारी नहीं है। शायद एनोटेटेड भाषा विनिर्देश इस पर कुछ प्रकाश डालेगा? –
दिलचस्प, धन्यवाद। यही कारण है कि मैं विशेष रूप से दिलचस्पी लेता हूं। –