सी #

Question

में शुद्ध कार्य मुझे पता है कि सी # को समानांतर प्रोग्रामिंग समर्थन मिल रहा है, लेकिन AFAIK अभी भी दुष्प्रभाव सत्यापन के लिए कोई संरचना नहीं है, है ना?

मुझे लगता है कि अब यह और अधिक मुश्किल है कि सी # पहले ही निर्धारित हो चुका है। लेकिन क्या इसमें शामिल होने की योजना है? या एफ # एकमात्र .NET भाषा है जिसने दुष्प्रभाव सत्यापन के लिए संरचना बनाई है?

Answer 1

सी # भाषा नहीं है, लेकिन .NET ढांचा हो सकता है।

संविदा पुस्तकालय + स्थिर विश्लेषण उपकरण .NET 4 में शुरू किया जा रहा इन परिचय हो सकता है:

माइक्रोसॉफ्ट [अपरिवर्तनीय] उपयोग कर रहा है और [शुद्ध] .NET 3.5 ढांचे के अंदर अभी।

उदाहरण के लिए, System.Core.dll में .NET 3.5 के अंदर [Microsoft.Contracts.Imutable] और [Microsoft.Contracts.Pure] देखें। दुर्भाग्यवश, वे आंतरिक हैं। हालांकि, माइक्रोसॉफ्ट। कॉन्ट्रैक्ट्स। * ज्यादातर स्पेक # अनुसंधान से पैदा हुआ है, और स्पेक # को अनुबंध एपीआई में जोड़ा गया है जो .NET 4.0 का हिस्सा होगा।

हम देखेंगे कि इसमें से क्या आता है। मैंने यह देखने के लिए जांच नहीं की है कि प्री-रिलीज .NET 4.0 बिट्स में अनुबंध एपीआई में [शुद्ध] या [अपरिवर्तनीय] जैसी कोई API शामिल है या नहीं। यदि वे करते हैं, तो मुझे लगता है कि स्थिर विश्लेषण उपकरण संकलक के बजाए नियम को लागू करने वाला होगा।

संपादित करें मैंने इस सप्ताह latest pre-release drop of MS Code Contracts से माइक्रोसॉफ्ट.कंट्राक्ट्स.dll को लोड किया। अच्छी खबर: [शुद्ध] और [व्यवहार्यता (Mutability.Imutable)] लाइब्रेरी में विशेषताएँ मौजूद हैं, जो बताती है कि वे .NET 4.0 में होंगे। वू हू!

संपादित करें 2 अब .NET 4 जारी किया गया है, मैंने इन प्रकारों को देखा। [Pure] अभी भी सिस्टम में है। डायग्नोस्टिक्स। नामस्थान का नियंत्रण करता है। यह सामान्य उपयोग के लिए नहीं है, बल्कि अनुबंध एपीआई के पूर्व और बाद की स्थिति की जांच के उपयोग के लिए है। यह संकलक लागू नहीं है, neither does the Code Contract checker tool enforce purity। [उत्परिवर्तन] चला गया है। दिलचस्प बात यह है कि, जहां माइक्रोसॉफ्ट .NET 3.5 (System.Core.dll में आंतरिक बिगइंटर श्रेणी में) में उत्परिवर्तन और शुद्ध विशेषताओं का उपयोग कर रहा था, .NET 4 ने BigInteger को System.Numerics में स्थानांतरित कर दिया है, और [शुद्ध] और [उत्परिवर्तन] को तोड़ दिया है उस प्रकार से गुण। नीचे पंक्ति: ऐसा प्रतीत होता है .NET 4 साइड इफेक्ट सत्यापन के लिए कुछ भी नहीं करता है।

संपादित के साथ हाल ही में (2011 देर से) 3 पूर्वावलोकन माइक्रोसॉफ्ट Rosyln संकलक-एज-ए-सेवा टूल - माना जाता है कि विजुअल स्टूडियो 2015 में RTM के लिए निर्धारित किए जाने की - देखो की तरह वे समर्थन करने के लिए सक्षम हो जाएगा इस तरह की चीजें; आप शुद्धता और अपरिवर्तनीयता की जांच करने के लिए कंपाइलर में एक्सटेंशन लिख सकते हैं, और उन विशेषताओं के साथ सजाए गए कुछ नियमों का पालन नहीं करते हैं, तो संकलक चेतावनियां जारी करते हैं। फिर भी, हम इसका समर्थन करने के लिए कुछ सालों से बाहर देख रहे हैं।

संपादित करें 4 अब रोज़िलन गर्मी 2015 के रूप में यहां है, शुद्ध/अपरिवर्तनीयता के लिए एक कंपाइलर एक्सटेंशन बनाने की क्षमता वास्तव में मौजूद है। हालांकि, यह मौजूदा फ्रेमवर्क कोड, न ही तृतीय पक्ष लाइब्रेरी कोड के लिए कुछ भी नहीं करता है। लेकिन क्षितिज पर C# 7 proposal for immutable types है। यह संकलक द्वारा लागू किया जाएगा और एनईटी फ्रेमवर्क में एक नया अपरिवर्तनीय कीवर्ड सी # और एक [अपरिवर्तनीय] विशेषता पेश करेगा। उपयोग:

// Edit #4: This is a proposed design for C# 7 immutable as of June 2015. 
// Compiler will implicitly mark all fields as readonly. 
// Compiler will enforce all fields must be immutable types. 
public immutable class Person 
{ 
    public Person(string firstName, string lastName, DateTimeOffset birthDay) 
    { 
     FirstName = firstName; // Properties can be assigned only in the constructor. 
     LastName = lastName; 
     BirthDay = birthDay; 
    } 

    public string FirstName { get; } // String is [Immutable], so OK to have as a readonly property 
    public string LastName { get; } 
    public DateTime BirthDay { get; } // Date is [Immutable] too. 
} 

संपादित 5 नवंबर वर्ष 2016 है, और ऐसा लगता है अपरिवर्तनीय प्रकार सी # 7 से हटा दिया गया वहाँ हमेशा आशा है सी # 8. :-)

संपादित 6 नवंबर 2017 है के लिए। सी # 8 पूर्ण दृश्य में आ रहा है, और जब हमारे पास शुद्ध कार्य नहीं होंगे, तो हमारे पास readonly structs होगा। यह एक संरचना अपरिवर्तनीय बनाता है, जो कई संकलक अनुकूलन की अनुमति देता है।

Answer 2

न केवल साइड-इफेक्ट सत्यापन के लिए कुछ भी नहीं है - यह सत्यापित करने के लिए कुछ भी नहीं है कि एक प्रकार अपरिवर्तनीय है, जो एक ही मार्ग आईएमओ के साथ एक छोटा कदम है।

मुझे विश्वास नहीं है कि सी # 4.0 में पाइप नीचे आने वाली कुछ भी है (हालांकि मैं आसानी से गलत हो सकता हूं)। मैं वास्तव में आशा है कि अपरिवर्तनीयता सी # 5.0 में प्रभाव डालती है; निश्चित रूप से एरिक लिपर्ट ने इसके बारे में काफी कुछ लिखा है, और एमएस में लोग समानांतरता के बारे में सोच रहे हैं।

क्षमा करें यह एक और अधिक उत्साहजनक तस्वीर नहीं है।

संपादित करें: Judah's answer काफी उज्जवल है ... क्या फ्रेमवर्क समर्थन आपके लिए पर्याप्त होगा? :) (मैं पूरी तरह से हैरान करता है, तो कोड संविदा के कुछ पहलुओं .NET 4.0 के लिए तैयार नहीं थे नहीं होगा, मन आप - अगर शायद वे आरंभिक रिलीज अपेक्षाकृत छोटा रखा और इसे बाद में बढ़ाया।)

Answer 3

सिद्धांत रूप में, यह सत्यापित करना कि कुछ अपरिवर्तनीय & है या नहीं, कोड में साइड इफेक्ट्स की कमी है या नहीं। कक्षा/डेटा संरचना के सभी क्षेत्रों को केवल पढ़ा जाना चाहिए और उनका प्रकार एक और अपरिवर्तनीय वस्तु होना चाहिए। हमें एक प्रतिनिधि को "शुद्ध" (दुष्प्रभाव मुक्त) के रूप में चिह्नित करने के लिए भी एक तरीका चाहिए, लेकिन शायद यह सब संभव होगा।

हालांकि, समस्या यह है कि यह अक्सर बहुत ही सीमित है। एफ # में, आप आम तौर पर एक साइड-इफेक्ट मुक्त & अपरिवर्तनीय शैली में कोड लिखते हैं, लेकिन स्थानीय रूप से कुछ उत्परिवर्तन का उपयोग करना अक्सर फायदेमंद होता है। यह समग्र शुद्धता को तोड़ता नहीं है (कुछ अर्थ में) और कोड लिखना बहुत आसान बनाता है। हालांकि, यह स्वचालित रूप से सत्यापित करना मुश्किल है (मतलब यह है कि यह एक दिलचस्प सैद्धांतिक समस्या है ..)

उदाहरण के लिए, "शुद्ध" तरीके से सरणी के साथ काम करना बिल्कुल ठीक है। आपके पास Array.map जैसी विधियां हो सकती हैं जो सभी तत्वों पर कुछ फ़ंक्शन लागू करती हैं और मूल को संशोधित किए बिना नया सरणी लौटाती हैं। फ़ंक्शन इसे वापस करने से पहले (नव निर्मित) सरणी को बदलता है, लेकिन सरणी कहीं और नहीं बदला जाता है, इसलिए यह सिद्धांत शुद्ध है, लेकिन सत्यापित करना मुश्किल है (और यह F # में काफी उपयोगी प्रोग्रामिंग पैटर्न है)।

तो, मुझे लगता है कि बहुत कुछ किया जा सकता है, लेकिन बस सभी साइड इफेक्ट्स पर प्रतिबंध लगाने के समान प्रतीत नहीं हो सकता है। अनुबंधों के बारे में अच्छी बात यह है कि शायद इस परिदृश्य में भी इसका इस्तेमाल किया जा सकता है।