अच्छा नहीं होगा अगर हमारे पास चीजों को अपरिवर्तनीय बनाने के लिए कुछ भाषा निर्माण हो? तब हमारे पास ये जादुई इंटरफेस नहीं होंगे।

@whoisj कौन सी भाषा? सीएलआर में उनमें से दर्जनों हैं।

यहां तक ​​​​कि एक संभावित भाषा सुविधा के रूप में इसे मेटाडेटा प्रतिनिधित्व की आवश्यकता होगी। इस मामले के लिए एक मार्कर इंटरफ़ेस (या व्यवहार इंटरफ़ेस) उतना ही अच्छा है जितना कोई। एक नई मेटाडेटा प्रविष्टि के माध्यम से संग्रह प्रकार की अपरिवर्तनीयता को व्यक्त करने का प्रयास करना उचित नहीं लगता क्योंकि सीएलआर को यह धारणा नहीं बनानी चाहिए कि एक मनमाना वर्ग आंतरिक रूप से कैसे कार्य करता है (और सीएलआर में संग्रह कक्षाओं की कोई अवधारणा नहीं है। सरणी)।

@whoisj मुझे लगता है कि इसे कम से कम भविष्य के सी # संस्करणों में से एक के लिए माना जाता है। लेकिन यह निर्णय सभी संग्रहों में सममित इंटरफेस की आवश्यकता को प्रभावित नहीं करता है। इसके अलावा मैं उन परिदृश्यों की कल्पना कर सकता हूं जहां परिवर्तनीय वस्तुओं की एक पठनीय सूची उपयोगी हो सकती है, उदाहरण के लिए उन खेलों में जो कोड गुणवत्ता और प्रदर्शन दोनों की परवाह करते हैं।

इसके अलावा अपरिवर्तनीय संग्रह पहले से ही उपलब्ध हैं:

https://msdn.microsoft.com/en-us/library/system.collections.immutable (v=vs.111).aspx

पूरी तरह से अपरिवर्तनीय संग्रह प्राप्त करने के लिए हमें केवल immutable T को परिभाषित करने का एक तरीका चाहिए और फिर इसका उपयोग Immutable...<T> संग्रह घोषित करने के लिए करें।

@HaloFour हम पहले इस सड़क से नीचे उतर चुके हैं: this )"।

@dsaf बिल्कुल! एक अन्य अंक में मैंने प्रस्तावित किया कि हमारे पास लिखने योग्य तत्वों के केवल पढ़ने योग्य संग्रह के उपयोग को सक्षम करने के लिए रीडोनली के लिए एक लिखने योग्य एंटी-टर्म है। readonly Bag<writable Element> की तर्ज पर कुछ।

मैंने सुझाव दिया कि & के साथ चिह्नित किसी भी संदर्भ को संकलक द्वारा अपरिवर्तनीय माना जाना चाहिए। मुझे अभी भी लगता है कि इसे केवल एक संकलन समय की जांच की आवश्यकता है, और अनिवार्य रूप से सीएलआर द्वारा ही लागू किया गया है क्योंकि मैं ज्यादातर तर्क के संकलन समय सत्यापन की मांग कर रहा हूं, न कि रन-टाइम गारंटी। इसमें कोई भी संदर्भ शामिल होगा जो डेवलपर्स अपरिवर्तनीय होना चाहते थे, लेकिन प्रति कॉल के आधार पर।

@whoisj शायद, लेकिन यह बहुत स्पर्शरेखा है और यह इस अनुरोध को कुछ dsaf से बदल देता है जो आज दोपहर को शाखा/पीआर कर सकता है जिसमें तीन अलग-अलग टीमों के प्रयास शामिल हैं।

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

मैं सहमत हूं कि यह अच्छा होगा यदि सी # भाषा और कंपाइलर को "शुद्ध" विधियों के लिए बेहतर समर्थन मिल सके। विशेषता PureAttribute पहले से मौजूद है लेकिन इसे छिटपुट रूप से उपयोग किया जाता है और इसके लिए वास्तव में कोई भाषा समर्थन नहीं है। और भले ही सी # ने कंपाइलर त्रुटियों के माध्यम से इसका समर्थन किया हो (शुद्ध केवल शुद्ध कॉल कर सकता है, आदि), यह एक अलग भाषा का उपयोग करके बहुत आसानी से पराजित हो जाता है। लेकिन इन तरीकों को खुद को घोषित करना होगा और खुद को लागू करना होगा क्योंकि एक बार आईएल में संकलित होने के बाद सभी दांव मूल रूप से बंद हो जाते हैं और कोई भी कंपाइलर झुक नहीं सकता है कि मौजूदा असेंबली कैसे निष्पादित होती है।

@HaloFour मेला।

मान लें कि हमारे पास "शुद्ध" या "कॉन्स्ट" संदर्भों का समर्थन करने का कोई सामान्य तरीका नहीं है, तो मुझे लगता है कि प्रस्तावित सबसे अच्छा विकल्प है।

यदि आपको अभी इसकी आवश्यकता है, तो मेरी कॉमन्स लाइब्रेरी (Commons.Collections https://github.com/yanggujun/commonsfornet/tree/master/src/Commons.Collections/Set ) में केवल पढ़ने के लिए सेट समर्थन है। व्यवस्थापक कृपया इस पोस्ट को हटा दें यदि इसे एक विज्ञापन के रूप में माना जाता है ... मेरा सुझाव है कि कुछ ओपन सोर्स कार्यान्वयन के लिए चारों ओर देखें।

@yanggujun सुझाव के लिए धन्यवाद, यह एक अच्छी लाइब्रेरी की तरह लगता है, लेकिन अतिरिक्त निर्भरताओं से बचने के लिए मैं अपना खुद का रोल करूंगा।

मेरा सुझाव है कि कुछ ओपन सोर्स कार्यान्वयन के लिए चारों ओर देखें।

यह एक कामकाज है, IReadOnlySet जैसे मौलिक इंटरफेस वास्तव में .NET फ्रेमवर्क का हिस्सा होना चाहिए।

क्या इसे "एपीआई समीक्षा के लिए तैयार" बनने के लिए एक स्पेकलेट की आवश्यकता है?

और जब हम इसमें हों, तो इसे "केवल पढ़ने के लिए" से कुछ अलग नाम देने पर विचार करें (दिलचस्प पोस्ट देखें: http://stackoverflow.com/questions/15262981/why-does-listt-implement-ireadonlylistt-in-net-4- 5)
"पठनीय" ठीक लगता है।

@GiottoVerducci नहीं। मैं एक सुसंगत नामकरण पैटर्न रखना पसंद करूंगा, भले ही वह अपूर्ण हो। हालांकि आप मौजूदा इंटरफेस का नाम बदलने के लिए एक अलग मुद्दा उठाने के लिए स्वतंत्र हैं।

प्रस्तावित एपीआई डिजाइन:

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
    bool IsSubsetOf(IEnumerable<T> other);
    bool IsSupersetOf(IEnumerable<T> other);
    bool IsProperSupersetOf(IEnumerable<T> other);
    bool IsProperSubsetOf(IEnumerable<T> other);
    bool Overlaps(IEnumerable<T> other);
    bool SetEquals(IEnumerable<T> other);
}

यह ISet<> API (स्पष्ट रूप से उत्परिवर्तन विधियों को छोड़कर) पर आधारित है।

यह अफ़सोस की बात है कि Comparer इसमें फिट नहीं बैठता है, लेकिन फिर न तो ISet<> और न ही IReadOnlyDictionary<> तुलनाकर्ताओं को बेनकाब करता है, इसलिए अब इसे ठीक करने में बहुत देर हो चुकी है।

    bool Contains(T item);

क्या यह इसके बजाय IReadOnlyCollection<T> में नहीं होना चाहिए क्योंकि ICollection<T> में Contains(T item) ?

अपरिवर्तनीय संग्रह पैकेज को अभी भी बीटा के रूप में nuget से असूचीबद्ध किया गया है।
मुझे लगता है कि यह एक बहुत ही सामान्य उपयोग का मामला है और इसे मानक कामों में संभाला जाना चाहिए।

क्या यहां एपीआई पर और काम करना है, जैसा कि टैग से पता चलता है? मुझे इस पर कुछ समय बिताने में खुशी हो रही है अगर यह मददगार होगा और कोई बता सकता है कि क्या आवश्यक है।

एपीआई @ashmind प्रस्तावित बहुत अच्छा लग रहा है।

क्या ISet<T> को IReadOnlySet<T> का विस्तार करने के लिए बनाया जा सकता है? ऐसा नहीं हुआ IList<T> / IReadOnlyList<T> ?

यदि नहीं, तो मुझे लगता है कि विचार करने के लिए अन्य परिवर्तन IReadOnlySet<T> को सभी ISet<T> कार्यान्वयन के लिए इंटरफ़ेस सूची में जोड़ रहे हैं जिसमें HashSet<T> , SortedSet<T> और उनके System.Collections.Immutable में अपरिवर्तनीय समकक्ष।

मुझे @GiottoVerducci से सहमत IReadOnlySet<T> जैसे नाम का उपयोग अनुबंध क्षमताओं की घोषणा नहीं करता है, यह अनुबंध सीमाओं की घोषणा करता है। फिर उसी अनुबंध का उपयोग दूसरे के साथ करना जो उन सीमाओं का खंडन करता है, भ्रमित करने वाला है। मेरा मानना ​​है कि अनुबंध के नाम में कार्यान्वयनकर्ता के समर्थन से संबंधित सकारात्मक अभिकथन का वर्णन होना चाहिए। माना जाता है कि IReadableSet<T> जैसा नाम महान नहीं है, लेकिन यह कम से कम बेहतर वर्णन करता है कि कार्यान्वयनकर्ता क्या करता है।

@HaloFour मैं सिद्धांत रूप में सहमत हूं, लेकिन अब हमारे पास वही स्थिति है IReadOnlyList<T> । निरंतरता बनाए रखना यहां सटीकता में वृद्धि को टंप करता है, IMHO।

@drewnoakes

मैं समझता हूं, और निरंतरता महत्वपूर्ण है। मुझे लगता है कि यह भी जवाब देता है कि ISet<T> को IReadOnlySet<T> विस्तार क्यों नहीं करना चाहिए।

निरंतरता बनाए रखना यहां सटीकता में वृद्धि को टंप करता है, IMHO।

मुझे लगता है कि यह भी जवाब देता है कि ISet<T> को IReadOnlySet<T> विस्तार क्यों नहीं करना चाहिए।

मुझे लगता है कि आप बिंदु खो रहे हैं। यही कारण है कि IList<T> , ICollection<T> , IDictionary<TKey, TValue> अलावा, ISet<T> , केवल-पढ़ने के लिए दृश्य इंटरफेस को लागू करने के लिए भी तय किया जाना चाहिए। अन्यथा बीसीएल के सहज ज्ञान युक्त डिजाइन के इर्द-गिर्द काम करते समय हर किसी को

@binki

मैं असहमत नहीं हूं। इसके बारे में मुझे जो पसंद नहीं है वह एक अनुबंध है जो पढ़ने-_केवल_ व्यवहार को अनुबंध द्वारा बढ़ाया जा रहा है जो पढ़ने-_लिखने_ व्यवहार को निर्धारित करता है। नामकरण गलत है और रचना गलत है। लेकिन हम यहाँ हैं। मुझे दोनों को बदलने के लिए वोट देना अच्छा लगेगा, लेकिन मुझे संदेह है कि ऐसा टेबल पर है।

@ हेलोफोर

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

मुझे यकीन नहीं है कि यहां केवल-पढ़ने के लिए गलत शब्द क्यों माना जाता है। केवल-पढ़ने के लिए _not_ अपरिवर्तनीय का संकेत देता है। एक संपूर्ण नगेट पैकेज/अलग एपीआई है (जहां जोड़ना/निकालना एक नई वस्तु उत्पन्न करता है और वर्तमान उदाहरण को कभी भी उत्परिवर्तित करने की गारंटी नहीं है-इस प्रकार अपरिवर्तनीय है) यदि आपको यही चाहिए।

मैं कुछ ऐसा ही सोच रहा था। .NET में "केवल पढ़ने के लिए" फ़ील्ड के लिए भी एक बहुत ही कमजोर गारंटी है। एक ओवर को देखते हुए, मुझे यकीन है कि यह सब अधिक समझ में आएगा। अभी के लिए यह व्यावहारिक होने लायक है।

तो सामान्य तौर पर, यदि कोई विधि IReadOnlySomething<T> स्वीकार करती है, तो आप सामान्य रूप से मान सकते हैं कि यह इसे संशोधित नहीं करेगा। इस बात की कोई गारंटी नहीं है कि प्राप्त करने की विधि संदर्भ को नहीं बढ़ाएगी, और इस बात की कोई गारंटी नहीं है कि इंटरफ़ेस का कार्यान्वयन आंतरिक रूप से खुद को तब तक संशोधित नहीं करेगा जब तक कि इसे एक्सेस न किया जाए।

सी ++ में, const_cast const की गारंटी को भी कमजोर करता है, जो शर्म की बात है (आजकल mutable संशोधक के साथ) लेकिन व्यवहार में यह कितना उपयोगी नहीं है const एक विशेषता के रूप में है। आपको बस यह जानना है कि आप किसके साथ काम कर रहे हैं।

@binki एक अच्छा भेद करता है। _अपरिवर्तनीय_ नाम में शामिल सभी के लिए समय के साथ स्थिरता की एक कठिन गारंटी का तात्पर्य है।

क्या किसी के पास कोई आधिकारिक स्रोत है कि क्यों IList<T> IReadOnlyList<T> विस्तार नहीं करता है?

@binki

एक इंटरफ़ेस एक दृश्य नहीं है, यह एक अनुबंध है। वह अनुबंध कार्यान्वयनकर्ता की क्षमताओं की घोषणा करता है। यदि कार्यान्वयनकर्ता वास्तव में उन क्षमताओं को लागू नहीं करता है तो मैं इसे अनुबंध उल्लंघन मानूंगा। वह List<T> वर्ग का दावा है कि यह "is-a" IReadOnlyList<T> , लेकिन ऐसा नहीं है। उसमें उस क्षमता का अभाव है।

इस विषय पर विचार के कई स्कूल हैं। मैं स्पष्ट रूप से उस स्कूल से संबंधित हूं जहां इंटरफ़ेस विरासत अधिक सख्ती से प्रकारों के बीच "एक-एक" संबंधों का पालन करती है। मैं निश्चित रूप से इंटरफेस के साथ रचना के लिए एक अधिक बारीक दृष्टिकोण का समर्थन करता हूं और सोचता हूं कि List<T> और उसके परिजनों को शायद कुछ 3-4 अतिरिक्त इंटरफेस (पढ़ें, लिखें, संलग्न करें, आदि) को लागू करने से लाभ हो सकता है, लेकिन मुझे निश्चित रूप से लगता है कि एक इंटरफ़ेस का नाम वर्णन करना चाहिए कि एक प्रकार _can_ क्या करता है, न कि यह क्या _can't_ करता है। नकारात्मक क्षमता के दावे अनुबंधों के लिए ज्यादा मायने नहीं रखते हैं।

@drewnoakes

अभी के लिए यह व्यावहारिक होने लायक है।

मैं सहमत हूं। हम जहां हैं वहीं हैं। यदि IList<T> को IReadOnlyList<T> का विस्तार करने के लिए बदला जाना था तो ISet<T> को विस्तारित करने के लिए IReadOnlySet<T> आदि को बदलना समझ में आता है।

क्या IReadableX<T> , IWritableX<T> , आदि इंटरफेस के लिए IReadOnlyX<T> साथ रहने के लिए भी धक्का देना अनावश्यक है?

क्या किसी के पास कोई आधिकारिक स्रोत है कि क्यों IList<T> IReadOnlyList<T> विस्तार नहीं करता है?

जाहिरा तौर पर पुराने .net ढांचे के खिलाफ संकलित असेंबली लोड करते समय यह एक एबीआई-ब्रेकिंग परिवर्तन होगा। क्योंकि एक इंटरफ़ेस को लागू करते समय, अधिकांश कंपाइलर स्वचालित रूप से स्पष्ट इंटरफ़ेस कार्यान्वयन उत्पन्न करेंगे, जब स्रोत कोड निहित इंटरफ़ेस कार्यान्वयन पर निर्भर करता है, यदि आपने अपनी कक्षा को IList<T> करने वाले BCL के विरुद्ध संकलित किया है जिसमें IList<T> IReadOnlyList<T> , कंपाइलर स्वचालित रूप से स्पष्ट IReadOnlyList<T> कार्यान्वयन नहीं बनाएगा। अगर मैं इसे सही पढ़ रहा हूं: http://stackoverflow.com/a/35940240/429091

@HaloFour चूंकि List<> और HashSet<> ICollection<> और IReadOnlyCollection<> , हमने पहले से ही एक रास्ता अपनाया है जहां IReadOnly पहुंच को संदर्भित करता है और नहीं क्षमता। उसके आधार पर, IAnything विस्तार IReadOnlyAnything सही समझ में आता है। मैं सहमत हूं कि IReadable IReadOnly से बेहतर है लेकिन इस समय हर कोई IReadOnly से _mean_ IReadable को समझता है और इसका उपयोग इस तरह करता है। वास्तव में, मैं जानबूझकर अपने कोडबेस में इसे कायम रख रहा हूं क्योंकि चीजों के बारे में सोचने के दो तरीके होने से मेरी राय में किसी भी चीज़ की तुलना में अधिक संज्ञानात्मक भार होता है।

हम नाम के साथ फंस गए हैं, लेकिन इसके पीछे की अवधारणा इतनी शक्तिशाली है कि मैं वास्तव में चाहता हूं कि सभी इंटरफेस के लिए IReadOnly आगे बढ़ना संभव हो, जैसे हम ठोस कक्षाओं के साथ करते हैं।

@ashmind मुझे लगता है कि यह सही है कि कोई भी CaseInsensitiveStringCollection या किसी ऐसे संग्रह से पास करने का कोई मतलब नहीं होगा जो एक निश्चित तुलना को दर्शाता हो।

(एक अजीब संग्रह के मामले में जो Contains(T, IEqualityComparer<T>) पहले से उपलब्ध विस्तार विधि की तुलना में अधिक कुशलता से कार्यान्वित करता है, यह शायद एक बार की कक्षा विधि होगी। यह कल्पना करना मुश्किल है कि Contains(T, IEqualityComparer<T>) आम है एक विशेष इंटरफ़ेस में समाप्त होने के लिए पर्याप्त है, लेकिन ऐसा होने से भी कुछ भी नहीं रोक रहा है।)

@jnm2

मुझे लगता है कि यह सही है कि कोई भी तरीका तुलनाकर्ता नहीं लेता है।

बस स्पष्ट करने के लिए, मैं यह कहना चाहता था कि इसे तुलनाकर्ता को बेनकाब करना चाहिए, एक को नहीं लेना चाहिए। चूंकि प्रत्येक सेट या डिक्शनरी में कुछ समानता एल्गोरिदम होना चाहिए, यह इंटरफ़ेस पर उजागर हो सकता था। लेकिन मुझे अब इसके लिए अपने उपयोग के मामले को याद नहीं है - एक ही तुलनाकर्ता का उपयोग करके एक सेट बनाने जैसा कुछ बाहरी रूप से प्रदान किया गया है।

हालांकि यह चर्चा बहुत सारे दिलचस्प बिंदुओं को सामने लाती है, लेकिन ऐसा लगता है कि यह उस सरल और स्पष्ट सुझाव से बहुत दूर है जिसने इस सूत्र को शुरू किया था। और यह हतोत्साहित करने वाला है क्योंकि मैं वास्तव में इस मुद्दे को संबोधित होते देखना चाहता हूं।

जैसा कि ओपी ने कहा, संग्रह प्रकारों के बीच समानता बनाए रखने में विफलता जब IReadOnlyList को IReadOnlySet के बिना जोड़ा गया था, दुर्भाग्यपूर्ण है और कई लोगों ने IReadOnlySet इंटरफ़ेस के अपने संस्करणों को वर्कअराउंड के रूप में लागू किया है (मेरी अपनी टीम का एक समान वर्कअराउंड है)। वे वर्कअराउंड इंटरफेस आदर्श नहीं हैं क्योंकि कोरएफएक्स कक्षाएं उन्हें लागू नहीं कर सकती हैं। ढांचे में इसे प्रदान करने का यह मुख्य कारण है: यदि मेरे पास हैशसेट है तो मैं इसे पहले से मौजूद ऑब्जेक्ट को कॉपी या लपेटने के बिना IReadOnlySet के रूप में उपयोग करने में सक्षम होना चाहता हूं। कम से कम प्रदर्शन के लिए यह अक्सर वांछनीय होता है।

इंटरफ़ेस का नाम स्पष्ट रूप से IReadOnlySet होना चाहिए। संगति IReadOnlyXXX नामों के साथ किसी भी चिंता को दूर करती है। वह जहाज रवाना हो गया है।

मौजूदा इंटरफेस में से कोई भी (IReadOnlyCollection) नहीं बदला जा सकता है। .NET के लिए बैक-कॉम्पैट आवश्यकताएँ उस तरह के परिवर्तनों की अनुमति नहीं देती हैं। यह दुर्भाग्यपूर्ण है कि मौजूदा IReadOnlyXXX इंटरफेस में तुलनाकर्ताओं का खुलासा नहीं किया गया है (मैंने इसमें भी भाग लिया है) लेकिन फिर से जहाज रवाना हो गया है।

एकमात्र प्रश्न जो व्यावहारिक दृष्टिकोण से बना रहता है, वह इंटरफ़ेस की इन दो संभावित परिभाषाओं के बीच है।

पहले @ashmind द्वारा प्रस्तावित:

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
    bool IsSubsetOf(IEnumerable<T> other);
    bool IsSupersetOf(IEnumerable<T> other);
    bool IsProperSupersetOf(IEnumerable<T> other);
    bool IsProperSubsetOf(IEnumerable<T> other);
    bool Overlaps(IEnumerable<T> other);
    bool SetEquals(IEnumerable<T> other);
}

न्यूनतम प्रस्ताव:

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}

व्यक्तिगत रूप से मैं इस न्यूनतम प्रस्ताव को पसंद करता हूं क्योंकि अन्य विधियों को प्राप्त किया जा सकता है; आदर्श रूप से IReadOnlySet इंटरफ़ेस पर विस्तार विधियों के रूप में उन लोगों का मानक कार्यान्वयन होगा, इसलिए IReadOnlySet के कार्यान्वयनकर्ताओं को उन्हें प्रदान करने की आवश्यकता नहीं है। मुझे यह भी लगता है कि यह न्यूनतम प्रस्ताव अन्य न्यूनतम IReadOnlyXXX इंटरफेस के अनुरूप है।

@ हारून-मेयर्स मेरी एकमात्र चिंता यह है कि IsSubsetOf और दोस्तों को _कुशल_ तरीके से Contains से प्राप्त नहीं किया जा सकता है। जब यह दो हैश टेबल होते हैं, उदाहरण के लिए, Contains पर निर्भर कार्यान्वयन को हैश मिलान के बजाय नेस्टेड लूप का उपयोग करने के लिए मजबूर करता है।

शायद एक नया इंटरफ़ेस, IComparableSet<T> में सेट ऑपरेशन शामिल हो सकते हैं।

कुछ सेट संचालन के लिए हमारे पास पहले से ही IEnumerable<T> पर विस्तार विधियां हैं।

@ jnm2 हैशसेट द्वारा उपयोग की जाने वाली इन विधियों के कार्यान्वयन के लिए केवल अन्य संग्रह को शामिल करना और गणना करना आवश्यक है (जो IReadOnlySet IReadOnlyCollection को विरासत में प्राप्त करेगा)। हालांकि यह जानने की आवश्यकता है कि दूसरा सेट एक ही तुलनाकर्ता का उपयोग करता है। शायद IReadOnlySet में तुलनित्र गुण जोड़ने के लायक है ताकि इन कार्यों को विस्तार विधियों में कुशलता से लागू किया जा सके। यह दुर्भाग्यपूर्ण है कि IReadOnlyDictionary KeyComparer को भी उजागर नहीं करता है, लेकिन इसे IReadOnlySet में जोड़ने के लायक हो सकता है, भले ही यह पूरी तरह से संगत न हो। अच्छे कारण हैं कि इसे पहले स्थान पर IReadOnlyDictionary पर शामिल किया जाना चाहिए था, जैसा कि यहां कवर किया गया है।

संशोधित प्रस्ताव होगा:

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    IEqualityComparer<T> Comparer { get; }
    bool Contains(T item);
}

वैकल्पिक रूप से, तुलनाकर्ता एक अलग इंटरफ़ेस पर हो सकता है और सेट संचालन के विस्तार विधि कार्यान्वयन केवल कुशल मार्ग का उपयोग करेंगे यदि दोनों ऑब्जेक्ट इंटरफ़ेस को लागू करते हैं और एक ही तुलनाकर्ता हैं। IReadOnlyDictionary के लिए एक ही दृष्टिकोण लागू किया जा सकता है (वास्तव में, शायद वे एक ही इंटरफ़ेस का उपयोग करते हैं)। ISetComparable जैसा कुछ। या @drewnoakes से आरेखण एक IComparableSet हो सकता हैलेकिन सेट ऑपरेटरों को परिभाषित करने के बजाय, यह सिर्फ तुलनाकर्ता को परिभाषित करता है:

public interface IComparableSet<T> : IReadOnlySet<T> {    
    IEqualityComparer<T> Comparer { get; }
}

इस मामले में IReadOnlySet केवल परिभाषित करने के लिए वापस चला जाता है:

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}
public interface IReadOnlySetEx<T> : IReadOnlySet<T> {    
    bool IsSubsetOf(IEnumerable<T> other);
    bool IsSupersetOf(IEnumerable<T> other);
    bool IsProperSupersetOf(IEnumerable<T> other);
    bool IsProperSubsetOf(IEnumerable<T> other);
    bool Overlaps(IEnumerable<T> other);
    bool SetEquals(IEnumerable<T> other);
    IEqualityComparer<T> Comparer { get; }
}
public class HashSet<T>: IReadOnlySetEx<T>, ISet<T>
{
   // Improved implementation here.
}

public static class CollectionExtensiosn
{
    public static IEqualityComparer<T> GetComparer<T>(this IReadOnlySet<T> @set)
    {
           var setEx = <strong i="5">@set</strong> as IReadOnlySetEx<T>;
           if (setEx == null)
           {
                throw new ArgumentException("set should implement IReadOnlySetEx<T> for this method.")
           }
           return setEx.Comparer;
    }

    public static bool IsSubsetOf<T>(this IReadOnlySet<T> <strong i="6">@set</strong>, IEnumerable<T> other)
    {
         var setEx = <strong i="7">@set</strong> as IReadOnlySetEx<T>;
         if (setEx != null)
         {
              return setEx.IsSubsetOf(other);
         }
         // Non optimal implementation here.
    }

    // The same approach for dictionary.
    public static IEqualityComparer<T> GetKeyComparer<T>(this IReadOnlyDictionary<T> dictionary)
    {
           var dictionaryEx = set as IReadOnlyDictionaryEx<T>;
           if (dictionaryEx == null)
           {
                throw new ArgumentException("dictionary should implement IReadDictionaryEx<T> for this method.")
           }
           return dictionaryEx.KeyComparer;
    }

}

हम इस दृष्टिकोण का उपयोग कर सकते हैं।
उपयोग इस तरह दिखेगा;

IReadOnlySet<string> mySet = new HashSet<string>();
bool test = mySet.IsSubsetOf(new []{"some", "strings", "set"}); // Extension method
var = mySet.GetComparer(); // Extension method

कई आवश्यकताओं को पूरा किया गया, IReadOnlySetन्यूनतर है। लेकिन GetComparer अब विधि, संपत्ति नहीं। लेकिन यह एक अच्छा व्यापार बंद है।

    /// <summary>
    /// Readable set abstracton. Allows fast contains method, also shows that collection items are unique by some criteria.
    /// </summary>
    /// <remarks>
    /// Proposal for this abstraction is discussed here https://github.com/dotnet/corefx/issues/1973.
    /// </remarks>
    /// <typeparam name="T">The type of elements in the set.</typeparam>
    public interface IReadOnlySet<out T> : IReadOnlyCollection<T>
    {
        /// <summary>
        /// Determines whether a <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified
        /// element.
        /// </summary>
        /// <typeparam name="TItem">The type of the provided item. This trick allows to save contravariance and save from boxing.</typeparam>
        /// <returns>
        /// true if the <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified element;
        /// otherwise, false.
        /// </returns>
        /// <param name="item">The element to locate in the <see cref="T:System.Collections.Generic.HashSet`1"/> object.</param>
        bool Contains<TItem>(TItem item);
    }

namespace System.Collections.Generic
{
    /// <summary>
    /// Provides the base interface for the abstraction of sets. <br/>
    /// This is full-featured readonly interface but without contravariance. See contravariant version
    /// <see cref="IReadOnlySet{T}"/>.
    /// </summary>
    /// <typeparam name="T">The type of elements in the set.</typeparam>
    public interface IReadableSet<T> : IReadOnlySet<T>
    {
        /// <summary>
        /// Gets the <see cref="Generic.IEqualityComparer{T}"/> object that is used to determine equality for the values
        /// in the set.
        /// </summary>
        /// <returns>
        /// The <see cref="Generic.IEqualityComparer{T}"/> object that is used to determine equality for the values in the
        /// set.
        /// </returns>
        IEqualityComparer<T> Comparer { get; }

        /// <summary>
        /// Determines whether a <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified
        /// element.
        /// </summary>
        /// <returns>
        /// true if the <see cref="T:System.Collections.Generic.HashSet`1"/> object contains the specified element;
        /// otherwise, false.
        /// </returns>
        /// <param name="item">The element to locate in the <see cref="T:System.Collections.Generic.HashSet`1"/> object.</param>
        bool Contains(T item);

        /// <summary>
        /// Determines whether the current set is a proper (strict) subset of a specified collection.
        /// </summary>
        /// <returns><see langword="true"/> if the current set is a proper subset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsProperSubsetOf(IEnumerable<T> other);

        /// <summary>Determines whether the current set is a proper (strict) superset of a specified collection.</summary>
        /// <returns>true if the current set is a proper superset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set. </param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsProperSupersetOf(IEnumerable<T> other);

        /// <summary>Determines whether a set is a subset of a specified collection.</summary>
        /// <returns>true if the current set is a subset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsSubsetOf(IEnumerable<T> other);

        /// <summary>Determines whether the current set is a superset of a specified collection.</summary>
        /// <returns>true if the current set is a superset of <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool IsSupersetOf(IEnumerable<T> other);

        /// <summary>Determines whether the current set overlaps with the specified collection.</summary>
        /// <returns>true if the current set and <paramref name="other"/> share at least one common element; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool Overlaps(IEnumerable<T> other);

        /// <summary>Determines whether the current set and the specified collection contain the same elements.</summary>
        /// <returns>true if the current set is equal to <paramref name="other"/>; otherwise, false.</returns>
        /// <param name="other">The collection to compare to the current set.</param>
        /// <exception cref="ArgumentNullException">
        /// <paramref name="other"/> is null.
        /// </exception>
        bool SetEquals(IEnumerable<T> other);
    }
}

इस अनुबंध को इंजेक्शन सहायकों के साथ nuget (https://www.nuget.org/packages/ClrCoder.Collections.ReadOnlySet) में प्रकाशित किया।
इसका उपयोग करने के लिए स्वतंत्र महसूस करें और यहां मुद्दे सबमिट करें: https://github.com/dmitriyse/ClrCoder/issues
यदि यह थोड़ा लोकप्रिय हो जाता है (शायद कुछ दौर के शोधन के बाद) तो हम CoreFX टीम को इस सुधार का सुझाव दे सकते हैं।

@terrajobst क्या मौजूदा वर्गों के लिए नए इंटरफेस को लागू करना ठीक है?

@safern List<T> में IReadOnly जोड़ने में उदाहरण है।

तो क्या इसे अगले .NET फ्रेमवर्क रिलीज में जोड़ने की योजना है?

यह काम कब धरातल पर आ रहा है? कोई समयसीमा?

https://www.nuget.org/packages/System.Collections.Immutable/
अपरिवर्तनीय संग्रह का पूरा सेट)

ठीक है। यह यहाँ बहुत पहले से है। मुझे इसकी बहुत आवश्यकता है और मैं इस बारे में एक तरीका प्रस्तावित करना चाहता हूं कि इस तक कैसे पहुंचा जाए।

इन सभी को उजागर करने के बजाय:

IEqualityComparer<T> Comparer { get; }
bool IsProperSubsetOf(IEnumerable<T> other);
bool IsProperSupersetOf(IEnumerable<T> other);
bool IsSubsetOf(IEnumerable<T> other);
bool IsSupersetOf(IEnumerable<T> other);
bool Overlaps(IEnumerable<T> other);
bool SetEquals(IEnumerable<T> other);

और ग्राहकों को इन सदस्यों को लागू करने के लिए मजबूर करते हुए, आइए बस वही जोड़ें जो सबसे महत्वपूर्ण है:

public interface IReadOnlySet<out T> : IReadOnlyCollection<T>
{
    bool Contains<T>(T item);
}

और कुछ नहीं। भविष्य में ऐसी आवश्यकता होने पर और API हमेशा जोड़े जा सकते हैं। लेकिन इसे हटाया नहीं जा सकता, इस प्रकार यह प्रस्ताव।

फिर हम इस इंटरफ़ेस को ISet<T> द्वारा विस्तारित इंटरफ़ेस की सूची में जोड़ देंगे।

दस्तावेज़ीकरण से

ISet<T> : यह इंटरफ़ेस सेट को लागू करने के तरीके प्रदान करता है, जो ऐसे संग्रह हैं जिनमें अद्वितीय तत्व और विशिष्ट संचालन होते हैं। हैशसेटऔर क्रमबद्धसेटसंग्रह इस इंटरफ़ेस को लागू करते हैं।

कोड से

ISet<T> इंटरफ़ेस में पहले से ही हमारी bool Contains<T>(T item); पद्धति ICollection<T> माध्यम से परिभाषित है। इसमें int Count { get; } वाया ICollection<T> ।

तो होगा:

public interface ISet<T> : ICollection<T>, IEnumerable<T>, IEnumerable, IReadOnlySet<T>

मामूली बदलाव, चर्चा के लिए कम, बड़ा लाभ।

कृपया इसे होने दें। मुझे बताएं कि क्या इस तरह के पुल अनुरोध को स्वीकार और विलय किया जाएगा। मैं इसे तब बना सकता हूं।

@karelz @terrajobst @safern @ianhays

वास्तविक दुनिया की समस्या पर काम करते समय मुझे यह चर्चा मिली, जहां मैं केवल पढ़ने के लिए सेट ऑपरेशन के लिए एक शब्दकोश के कुंजी संग्रह का उपयोग करना चाहता था। उस मामले का समर्थन करने के लिए यहां वह एपीआई है जिसका मैं प्रस्ताव करता हूं।

दलील

प्रस्तावित एपीआई

 namespace System.Collections.Generic {
+    public interface IReadOnlySet<out T> : IReadOnlyCollection<T>, IEnumerable, IEnumerable<T> {
+        bool Contains(T value);
+        bool IsProperSubsetOf(IEnumerable<T> other);
+        bool IsProperSupersetOf(IEnumerable<T> other);
+        bool IsSubsetOf(IEnumerable<T> other);
+        bool IsSupersetOf(IEnumerable<T> other);
+        bool Overlaps(IEnumerable<T> other);
+        bool SetEquals(IEnumerable<T> other);
+    }
-    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
-    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
+    public class ReadOnlySet<T> : ICollection<T>, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, IReadOnlySet<T>, ISet<T> {
+        public int Count { get; }
+        public ReadOnlySet(ISet<T> set);
+        public bool Contains(T value);
+        public bool IsProperSubsetOf(IEnumerable<T> other);
+        public bool IsProperSupersetOf(IEnumerable<T> other);
+        public bool IsSubsetOf(IEnumerable<T> other);
+        public bool IsSupersetOf(IEnumerable<T> other);
+        public bool Overlaps(IEnumerable<T> other);
+        public bool SetEquals(IEnumerable<T> other);
+    }
     public class Dictionary<TKey, TValue> {
-        public sealed class KeyCollection : ICollection, ICollection<TKey>, IEnumerable, IEnumerable<TKey>, IReadOnlyCollection<TKey> {
+        public sealed class KeyCollection : ICollection, ICollection<TKey>, IEnumerable, IEnumerable<TKey>, IReadOnlyCollection<TKey>, IReadOnlySet<TKey> {
+            public bool IsProperSubsetOf(IEnumerable<TKey> other);
+            public bool IsProperSupersetOf(IEnumerable<TKey> other);
+            public bool IsSubsetOf(IEnumerable<TKey> other);
+            public bool IsSupersetOf(IEnumerable<TKey> other);
+            public bool Overlaps(IEnumerable<TKey> other);
+            public bool SetEquals(IEnumerable<TKey> other);
         }
     }
 }

प्रश्न खोलें

• क्या इन विधियों को Dictionary<TKey, TValue>.KeyCollection जोड़ना स्वीकार्य है, जिसे सामान्य रूप से तत्काल जेनेरिक प्रकार के लिए कोड आकार की लागत दी गई है? यहां देखें।
• क्या IReadOnlySet<T> को अन्य Dictionary KeyCollection जैसे SortedDictionary या ImmutableDictionary ?

अपडेट

• निकाला गया TryGetValue के रूप में यह में नहीं है ISet<T> और जैसे संभावित कभी रिबेसिंग रोका जा सके ISet<T> लागू करने के लिए IReadOnlySet<T> ।
• जोड़ा गया ReadOnlySet<T> वर्ग जो ReadOnlyCollection<T> ।

@TylerBrinkley धागे में एक एपीआई प्रस्ताव जोड़ने के लिए धन्यवाद। क्या आप तर्क जोड़ना और मामलों का उपयोग करना चाहेंगे? ताकि मैं इसे समीक्षा के लिए तैयार कर सकूं और एपीआई विशेषज्ञों को निर्णय लेने दूं?

@TylerBrinkley IReadOnlySet में EqualityComparer संपत्ति को शामिल करना न भूलेंइंटरफेस। वे वर्तमान में कोरएफएक्स में डिक्शनरी और सेट में छूट गए हैं, लेकिन यह एक मुद्दा है।

@dmitriyse केवल IEqualityComparer<T> संपत्ति पाने वाले का क्या उपयोग होगा? आप इससे क्या करेंगे?

सही संग्रह क्लोनिंग की अनुमति देने के लिए शब्दकोशों और सेटों को अपने समानता तुलनाकर्ताओं की रिपोर्ट करनी चाहिए।
दुर्भाग्य से मैं भूल गया कि इस मुद्दे पर कहाँ चर्चा की गई थी।

यदि आप क्लोनिंग कर रहे हैं तो क्या आप एक ठोस प्रकार के साथ काम नहीं कर रहे होंगे? इंटरफ़ेस को IEqualityComparer<T> का समर्थन करने की आवश्यकता क्यों होगी?

उदाहरण के लिए यदि आपने स्ट्रिंग्स और केस असंवेदनशीलता समानता तुलनाकर्ता के साथ सेट किया है, तो आपको सही EqualityComparer निर्दिष्ट किए बिना एक नया हैशसेट बनाने पर एक अपवाद प्राप्त होगा। ऐसे मामले हैं जब आप यह नहीं जान सकते हैं कि निर्दिष्ट सेट में EqualityComparer का क्या उपयोग किया जाता है।

यह सिर्फ क्लोनिंग नहीं है। मुझे लगता है कि कहीं अधिक सामान्य परिदृश्य दो सेटों की तुलना कर रहा है - मुझे यह जानने की जरूरत है कि वे दोनों एक ही तुलनाकर्ता का उपयोग करते हैं ताकि कंटेन्स का उपयोग करके एक इष्टतम तुलना को लागू किया जा सके। मुझे लगता है कि इस धागे में एक उदाहरण है।

उस ने कहा, मेरे पास केवल शामिल विधि के साथ IReadOnlySet नहीं होगा। सेट तुलना को सामान्य रूप से लागू करने में सक्षम होना अच्छा होगा, लेकिन उतना सामान्य नहीं जितना कि किसी सेट के केवल-पढ़ने के लिए संदर्भ की आवश्यकता होती है।

आईओएस के लिए आउटलुक प्राप्त करें https://aka.ms/o0ukef

से: टायलर ब्रिंकले नोटिफिकेशन @github.com
भेजा गया: गुरुवार, 10 मई, 2018 6:21:52 पूर्वाह्न
प्रति: डॉटनेट/कोरएफएक्स
सीसी: हारून मेयर्स; उल्लेख
विषय: पुन: [डॉटनेट/कोरएफएक्स] कृपया इंटरफ़ेस IReadOnlySet जोड़ें और हैशसेट बनाएं, सॉर्टेडसेट इसे लागू करें (#1973)

यदि आप क्लोनिंग कर रहे हैं तो क्या आप एक ठोस प्रकार के साथ काम नहीं कर रहे होंगे? इंटरफ़ेस को IEqualityComparer का समर्थन करने की आवश्यकता क्यों होगी.

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें % 7C01% 7C% 7Cc45ea16cd3034ddd69d808d5b678ff33% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636615553141417289 और sdata = xRI27JtyaAwnZ2anY05oTlxmPY5AaGVl% 2BRdXK2uR0% 2F8% 3 डी और = 0 सुरक्षित , या धागे मूक https://eur01.safelinks.protection.outlook.com/?url=https%3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe लेखन% 2FAMuQLmqboBWyHweWHSUoE1YM2OrfHZZxks5txD7wgaJpZM4E9KK- और डेटा = 02% 7C01% 7C% 7Cc45ea16cd3034ddd69d808d5b678ff33% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636615553141417289 और sdata = hLtAXEyFNVEgWike6tMwAfUVC% 2BucyjXUDwoLOLDV5gk% 3 डी और = 0 आरक्षित ।

मैं सहमत हूं—आप यह बता सकते हैं कि सेट में आपको किस प्रकार के डुप्लिकेट मिल सकते हैं (केस सेंसिटिव, केस असंवेदनशील, आदि) केवल तुलनाकर्ता को उजागर करके है।

मुझे लगने लगा है कि मेरे प्रस्ताव को स्वीकार नहीं किया जाएगा क्योंकि उन सभी विधियों को Dictionary<TKey, TValue>.KeyCollection में जोड़ने से कोड आकार की महत्वपूर्ण लागत आएगी। सामान्य रूप से तत्काल सामान्य प्रकारों में नया एपीआई जोड़ने के संबंध में यह चर्चा देखें।

मुझे नहीं लगता कि आप IReadOnlySet पर तुलना करने में सक्षम होंगे।

SortedSet एक IComparer SortedSet लेता है, जबकि HashSet एक IEqualityComparer लेता है।

अच्छा बिंदु, तुलनाकर्ता को एक कार्यान्वयन विवरण माना जा सकता है जो सामान्य इंटरफ़ेस से संबंधित नहीं है।

आईओएस के लिए आउटलुक प्राप्त करें https://aka.ms/o0ukef

से: कोरी नेल्सन सूचनाएं @github.com
भेजा गया: गुरुवार, मई 10, 2018 5:04:06 अपराह्न
प्रति: डॉटनेट/कोरएफएक्स
सीसी: हारून मेयर्स; उल्लेख
विषय: पुन: [डॉटनेट/कोरएफएक्स] कृपया इंटरफ़ेस IReadOnlySet जोड़ें और हैशसेट बनाएं, सॉर्टेडसेट इसे लागू करें (#1973)

मुझे नहीं लगता कि आप IReadOnlySet पर तुलना करने में सक्षम होंगे।

SortedSet एक IComparer लेता है, जबकि HashSet एक IEqualityComparer लेता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcorefx%2Fissues%2F1973%23issuecomment-388221165&data=02 % 7C01% 7C% 7C0ef6d84125be4c450fdc08d5b6d2b70a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636615938478979295 और sdata = PHkDQPiJBEIks8yNyIA7vKODM% 2BkMFI4PRX4lUUBu% 2Bi0% 3 डी और = 0 सुरक्षित , या धागे मूक https://eur02.safelinks.protection.outlook.com/?url=https%3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe लेखन% 2FAMuQLu5JGLcqrpMyGWLygbCsaSQSXFgNks5txNV2gaJpZM4E9KK- और डेटा = 02% 7C01% 7C% 7C0ef6d84125be4c450fdc08d5b6d2b70a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636615938478979295 और sdata = 9pnuMULuDu9HWb7un% 2FWYq6iYdjTKFsjN7nKiToaeHkk% 3 डी और = 0 आरक्षित ।

IUnorderedSet और IOrderedSet इंटरफेस जोड़ने में कुछ मूल्य हो सकता है, लेकिन मैं नहीं चाहता कि यह IReadOnlySet माध्यम से धक्का दे।

मुझे @pgolebiowski का सुझाव पसंद है लेकिन उस इंटरफ़ेस को और भी बुनियादी बना देगा।

c# public interface ISetCharacteristic<in T> { bool Contains(T item); }

यह तब अंतराल (वास्तविक) जैसे बेशुमार सेटों के लिए भी उपयुक्त है। उस और IReadOnlySet आप संभावित रूप से कुछ अन्य इंटरफेस जैसे ICountableSet (उर्फ IEnumerableSet ), IUnorderedSet और IOrderedSet में फिट हो सकते हैं।

लेकिन सहमत हैं कि केवल IReadOnlySet वर्तमान में जो उपलब्ध है, उस पर एक बड़ा सुधार होगा।

@NickRedwood . के लिए +1

यह अब 3 साल से अधिक समय से खुला है। कृपया दृष्टिकोण बदलकर ऐसा करें। @NickRedwood द्वारा उल्लिखित परिवर्तन का परिचय अन्य सभी संवर्द्धन की अनुमति देता है

@TylerBrinkley @safern @karelz @terrajobst

मैं वास्तव में केवल Contains विधि के साथ IReadOnlySet<T> इंटरफ़ेस के लिए इतना लाभ नहीं देखता हूं। जबकि यह विधि उपयोगी है, यह पहले से ही ICollection<T> इंटरफ़ेस में शामिल है जिसमें IsReadOnly संपत्ति भी है जिसका उद्देश्य यह इंगित करना है कि ICollection<T> के संशोधन विधियां समर्थित हैं या नहीं। बस ICollection<T> और IsReadOnly वापसी true । केवल अन्य कार्यक्षमता जो समर्थन की उम्मीद की जाएगी वह Count संपत्ति होगी, गणना योग्य होगी, और एक CopyTo विधि जो बहुत सीमित प्रतीत नहीं होती है।

प्रस्तावित के लिए मैं बहुत खुश होगा IReadOnlySet<T> के आधार पर लागू किया जाना IReadOnlyCollection<T> - यह क्या वर्तमान में उपलब्ध है पर एक बड़ा सुधार होगा। ( @TylerBrinkley - मान लें कि आपका मतलब IReadOnlyCollection<T> बजाय ICollection<T> ।

मुझे लगता है कि मैं अधिक बुनियादी इंटरफेस के पक्ष में गलती करता हूं, और यदि सेट के लिए कोई एक था तो यह Contains विधि के साथ एकल-विधि-इंटरफ़ेस होगा। इसका एक अच्छा गणितीय आधार है और यह बहुत साफ है। हालांकि जब मौजूदा कक्षाओं में रेट्रोफिटिंग करते हैं तो मैं स्वीकार करता हूं कि कम रेट्रोफिटिंग बेहतर है, और यदि केवल एक इंटरफ़ेस को फिर से लगाया जाना था तो IReadOnlySet<T> आधार पर IReadOnlyCollection<T> होना चाहिए।

IReadOnlyCollection<> में .Contains क्योंकि यह इसे सहसंयोजक होने से रोकेगा।

अच्छी बात है और मैंने अपनी पिछली पोस्ट को contravariant होने के लिए सही किया है। IReadOnlySet<T> को अपरिवर्तनीय होने की आवश्यकता होगी जब तक कि थ्रेड में जल्दी पोस्ट किए गए दृष्टिकोण का उपयोग नहीं किया जाता है, और मैं इसके बारे में अनिश्चित हूं।

@TylerBrinkley व्यक्तिगत रूप से मैं IsReadOnly संपत्ति का प्रशंसक नहीं हूं, मुझे यह जानकारी रन-टाइम के बजाय संकलन-समय पर ज्ञात होगी। यदि आप IReadOnlyCollection<T> इंटरफ़ेस का जिक्र कर रहे थे तो मुझे अभी भी लगता है कि कॉलर या कैली के लिए यह जानना उपयोगी होगा कि संग्रह के बावजूद संभावित पुनरावृत्ति के बजाय लुकअप तेज़ होगा, हालांकि मुझे यकीन नहीं है कि क्या एक "सेट" का तात्पर्य है।

केवल Contains विधि होने से यह परिभाषित नहीं होता है कि Set को क्या करना चाहिए, बस एक Collection को क्या करना चाहिए। मेरा मतलब है कि Contains ISet का सदस्य भी नहीं है बल्कि ICollection जो ISet विरासत में मिला है। ISet अन्य सदस्यों को यह परिभाषित करने की आवश्यकता होनी चाहिए कि Set को क्या करना चाहिए। मैं समझता हूं कि ज्यादातर लोग शायद इसकी Contains विधि के लिए विशेष रूप से सेट का उपयोग करते हैं, लेकिन इसके अलावा सेट के लिए और भी बहुत कुछ है।

@TylerBrinkley लेकिन क्या इस बिंदु पर IReadOnlyCollection<T>.Contains(T) को परिभाषित करना भी संभव है? मैंने माना नहीं। इसलिए एकमात्र विकल्प IReadOnlySet<T> पेश करना है और जब पेश किया जाता है, तो सुनिश्चित करें कि उस पर IReadOnlySet<T>.Contains(T) घोषित किया गया है।

@ जेएनएम 2 कहते हैं:

IReadOnlyCollection<> में .Contains क्योंकि यह इसे सहसंयोजक होने से रोकेगा।

यह मेरे लिए अभी सबसे बड़ा मुद्दा लगता है। IReadOnlySet<T> का अपरिवर्तनीय होना अजीब होगा जब IReadOnlyCollection<T> सहसंयोजक हो। ऐसा लगता है कि कई मौजूदा IReadOnly* इंटरफेस को ध्यान से out T किया गया था, जिसमें लिखने योग्य इंटरफेस अनिवार्य रूप से अपरिवर्तनीय थे। हम में से अधिकांश चाहते हैं कि IReadOnlySet<T> कम से कम एक Contains(T) विधि घोषित करें और फिर भी यह इसे सहसंयोजक होने से रोकेगा।

यदि ICollection वास्तव में Contains(T) को परिभाषित करने के लिए सही जगह है, तो क्या यह संभव है? शायद IReadOnlyProbableCollection<T>.Contains(T) जो अपरिवर्तनीय होगा और Collection<T> और HashSet<T> द्वारा लागू किया जाएगा?

मुझे लगता है कि @ NickRedwood का ISetCharacteristic<T> का सुझाव शायद क्लीनर लगता है। यहां तक ​​​​कि आपको Count को लागू न करने की अनुमति देने का भी लाभ है जो उपयोगी हो सकता है।

व्यक्तिगत रूप से मैं IsReadOnly संपत्ति का प्रशंसक नहीं हूं, मुझे यह जानकारी रन-टाइम के बजाय संकलन-समय पर ज्ञात होगी।

वह आदमी अच्छा बोलता है, उसे और शराब पिलाओ।

@binki मैं वहाँ एक होने की जरूरत है इस बात से सहमत Contains पर विधि IReadOnlySet<T> के बाद से IReadOnlyCollection<T> एक को शामिल नहीं किया, फिर भी मैं यह भी लगता है कि अन्य सभी गैर-परिवर्तनशील ISet<T> विधियों को शामिल किया जाना चाहिए।

Dictionary.KeyCollection उपयोग मामले के अलावा मैंने ऊपर उल्लेख किया है कि इस इंटरफ़ेस को जोड़ने के लिए आप किन अन्य उपयोग मामलों के साथ आ सकते हैं?

ठीक है, ऐसा लगता है कि एपीआई डिज़ाइन है:

public interface IReadOnlySet<T> : IReadOnlyCollection<T> {    
    bool Contains(T item);
}

यह डिजाइन का एकमात्र सामान्य हिस्सा है जिससे हर कोई सहमत होने में सक्षम लगता है।

मैं कहता हूँ कि अब हम यहाँ डिज़ाइन समाप्त करते हैं। यदि आप इसे भविष्य में विस्तारित करना चाहते हैं, तो इसे एक अलग मुद्दे में करें। यह सबसे महत्वपूर्ण कार्यक्षमता है जो प्रोड में होनी चाहिए।

किसके लिए है, किसके खिलाफ है?

मुझे @ashmind का सुझाव पसंद है । यह बहुत अच्छा होगा यदि Dictionary.Keys इस इंटरफ़ेस को लागू कर सकते हैं क्योंकि यह तकनीकी रूप से IReadOnlySet<TKey> ।

क्या आप कृपया इसे api-ready-for-review रूप में चिह्नित कर सकते हैं? मैंने अभी पाया है कि मुझे इस इंटरफ़ेस की फिर से आवश्यकता है और यह अभी भी नहीं है।

इसे अभी तक लागू क्यों नहीं किया गया?

[संपादित करें] क्षमा याचना - मेरा मूल उत्तर किसी अन्य एपीआई के साथ मिला हुआ था। इस बारे में मेरी कोई मजबूत राय नहीं है, पाठ संपादित। गड़बड़ी के लिए क्षमा!

इसे अभी तक लागू क्यों नहीं किया गया?

एपीआई पर अभी तक क्षेत्र के मालिकों का ध्यान नहीं गया - @safern। मुझे यकीन नहीं है कि यह संग्रह प्राथमिकता सूची में कितना ऊंचा है। अपवोट की संख्या काफी ज्यादा है।
सच्चाई यह है कि अब हम .NET Core 3.0 के लिए लॉक डाउन कर रहे हैं, इसलिए इसे अगली रिलीज के लिए कम से कम इंतजार करना होगा क्योंकि यह 3.0 के लिए महत्वपूर्ण नहीं है।

मुझे भी आश्चर्य है कि यह लीक से हटकर उपलब्ध नहीं कराया गया है।

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

इसके बिना, पैरामीटर/रिटर्न वैल्यू के रूप में एक अपरिवर्तनीय सेट का उपयोग करने के लिए प्रत्येक पुस्तकालय को या तो IEnumerable का उपयोग करने की आवश्यकता होती है जो कम कुशल और अर्थपूर्ण रूप से गलत है या अपने स्वयं के इंटरफेस/कक्षाओं का उपयोग अपने हस्ताक्षर में करता है जो किसी और के साथ असंगत है।

मैं उत्सुक हूं कि इसके लिए कोई कामकाज है जो Contains लुकअप के मामले में कुशल है और पैरामीटर/वापसी मूल्य के ठोस प्रकार को निर्दिष्ट करने से बचें। सबसे अच्छा मैं अपने सिर के ऊपर से सोच सकता हूं कि हस्ताक्षर में IEnumerable का उपयोग करना और ReadOnlyDictionary.Keys पास करना होगा, लेकिन यह थोड़ा बुरा लगता है, खासकर पुस्तकालय में। चूंकि Enumerable.Contains लिंक में Contains के संग्रह कार्यान्वयन का उपयोग करेगा, यह संगत होने पर कुशल होना चाहिए, लेकिन उस इरादे को संवाद नहीं करता है जिससे कम प्रदर्शन करने वाले कार्यान्वयन का उपयोग हो सकता है।

@ adamt06 आप ISet<T> ढूंढ रहे हैं।

@scalablecory आप अपरिवर्तनीय कार्यान्वयन के साथ सही हैं, और एक है: ImmutableHashSet<T>

क्या कोई जानता/समझता है कि क्यों ICollectionIReadOnlyCollection का विस्तार नहीं करता है??
मुझे लगा कि यह इस धागे से थोड़ा संबंधित है। मेरे बजाय एक नया सूत्र खोलना। शायद मैं कुछ गलत समझ रहा हूँ।

एक और विचार, लेकिन पूरी तरह से विषय से दूर, और ReaOnlyCollection में क्यों नहीं है:

c# bool Contains(T item); void CopyTo(T[] array, int arrayIndex);

ब्रेकिंग परिवर्तनों के साथ कुछ करना है, लेकिन मुझे विवरण याद नहीं है।

ReadOnlyCollection में वे चीजें हैं:
https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.readonlycollection-1.contains
https://docs.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.readonlycollection-1.copyto

ओह, मुझे लगता है कि आपका मतलब IReadOnlyCollection में नहीं है। ऐसा इसलिए है क्योंकि अन्यथा इंटरफ़ेस सहसंयोजक नहीं हो सकता।

मुझे यकीन नहीं है, लेकिन शायद यह स्पष्ट इंटरफ़ेस कार्यान्वयन के साथ कुछ करने के लिए है जो पिछली संगतता के साथ समस्याएं पैदा कर रहा है। मैं देख सकता हूं कि मौजूदा इंटरफेस को एक समस्या होने से अन्य इंटरफेस से प्राप्त करने के लिए क्यों अपडेट किया जा रहा है, लेकिन मुझे नहीं लगता कि एक नया इंटरफ़ेस IReadOnlySet<T> क्यों बनाना और HashSet लागू करना एक मुद्दा होगा।

ठीक है। लेकिन अभी भी ICollection नहीं दिख रहा हैनहीं होना चाहिए:
c# ICollection<T> : IReadOnlyCollection<out T>
एक पठन/लेखन संग्रह भी केवल पढ़ने योग्य संग्रह का विस्तार क्यों नहीं होना चाहिए?

@ जेनेरिक0

ठीक है। लेकिन अभी भी नहीं दिख रहा है ICollection नहीं होना चाहिए:

ICollection<out T> : IReadOnlyCollection<out T>

एक पठन/लेखन संग्रह भी केवल पढ़ने योग्य संग्रह का विस्तार क्यों नहीं होना चाहिए?

सबसे पहले, कृपया ध्यान दें कि ICollection<out T> घोषित करना असंभव है क्योंकि ICollection<T> में एक सदस्य .Add(T item) ।

दूसरा, ध्यान दें कि ICollection<T> .net-2.0 में दिखाई देता है और IReadOnlyCollection<out T> .net-4.5 में दिखाई देता है । यदि आप ICollection<T> को लागू करने के रूप में कोड संकलित करते हैं और फिर एक नए इंटरफ़ेस को लागू करने के लिए ICollection<T> को बदल दिया जाता है, तो कोई भी मौजूदा संकलित बायनेरिज़ रनटाइम पर टूट जाएगा क्योंकि केवल ICollection<T> को लागू करने वाली कोई भी चीज़ नहीं होगी IReadOnlyCollection<T> संकलक द्वारा (संभवतः स्वचालित रूप से) भरे गए स्लॉट। यह संगतता समस्या है जिसने ICollection<T> को IReadOnlyCollection<T> को लागू करने से रोका।

मुझे नहीं लगता कि यह इस SO उत्तर द्वारा स्पष्ट रूप से संबोधित किया गया है, लेकिन इसके लिए एक SO है: https://stackoverflow.com/a/14944400 ।

@binki " "आईसीओलेक्शन के लिए तय किया गया, मेरे टाइपो को इंगित करने के लिए धन्यवाद ..
डॉटनेटस्टैंडर्ड और नेट461. और यहीं बदलाव होना चाहिए। नेटस्टैंडर्ड 2+

मैं दोहराऊंगा ...
एक पठन/लेखन संग्रह भी केवल पढ़ने योग्य संग्रह का विस्तार क्यों नहीं होना चाहिए?

और किसी को संग्रह को कास्ट करने की आवश्यकता क्यों है उदाहरण के लिए "ToArray ()" बस कम बेनकाब करने के लिए?

और क्योंकि आप चीजों को तोड़े बिना उच्च संस्करणों में नए इंटरफेस जोड़ सकते हैं। ICollection में पहले से ही IReadOnlyCollection विधियां लागू हैं। नोटिंग टूटनी चाहिए...:-/

@ Generik0 ऐसा लगता है कि यह स्रोत संगतता को नहीं तोड़ेगा जो आप सोच रहे हैं [सोच नहीं रहे थे; यह होगा], लेकिन यह बाइनरी संगतता को तोड़ देगा जो आईएल टेबल के साथ काम करता है, सी # नहीं।

ठीक है @ jnm2 धन्यवाद।
मैं अपने ऑफ टॉपिक शेख़ी को अब बंद कर दूंगा, जरा सोचिए कि यह खराब आर्किटेक्चर है। सुनने/समझाने के लिए सभी का धन्यवाद :-)

@jnm2

@ Generik0 ऐसा लगता है कि यह स्रोत संगतता को नहीं

नाइटपिक (क्षमा करें) के लिए, यदि आपका स्रोत स्पष्ट रूप से ICollection<T> को .net-4.5 से पहले लागू करता है तो यह स्रोत संगतता को भी तोड़ देगा। IReadOnlyCollection<T>.Count को स्पष्ट रूप से लागू करने में विफलता के कारण वर्ग संकलन करने में विफल होना शुरू हो जाएगा। लेकिन द्विआधारी संगतता एक बड़ा सौदा है क्योंकि यह आपको .net संस्करणों की एक विस्तृत श्रृंखला को लक्षित करने से रोकेगा (आपको ≥.net-4.5 पर चलने के लिए अलग-अलग बायनेरिज़ रखने होंगे <.net-2 की परवाह किए बिना और आप पुराने ढांचे को लक्षित करने के बजाय दोनों को लक्षित करना है)।

मैं सोच रहा हूं कि सी # 8 में डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन समर्थन के अतिरिक्त यदि ICollection<T> .NET कोर 3.0+ के लिए IReadOnlyCollection<T> लागू कर सकता है।

शायद एक विस्तार की जरूरत है, तो यह कम से कम एक ही संग्रह है। यानी अगर आपको केवल पढ़ने के लिए संग्रह के लिए एक संख्या या संग्रह प्राप्त करने की आवश्यकता है ... कोई विचार?

[ @ jnm2 टिप्पणी द्वारा संपादित]
c# public static class CollectionExtensions { public static IReadOnlyCollection<T> CastAsReadOnlyCollection<T>(this IEnumerable<T> collection) { if((collection is IReadOnlyCollection<T> readOnlyCollection )) { return readOnlyCollection ; } throw new ArgumentException($"{collection.GetType()} not supported as readonly collection"); } }

@ Generik0 उस विधि को कॉल करने के बजाय enumerable as IReadOnlyCollection<T> ?? throw ... या (IReadOnlyCollection<T>)enumerable उपयोग क्यों न करें?

@ जेएनएम 2 ओम । तुम सही हो। कभी-कभी आप स्पष्ट तस्वीर नहीं देखते हैं और चीजों को उलझा देते हैं !!!

मैं अभी भी विस्तार को कॉल करूंगा, बस सादगी पाने के लिए ;-)
धन्यवाद दोस्त....

यहां क्या स्थिति है? मैं वास्तव में इस इंटरफ़ेस को मानक lib में पसंद करता हूं और हैशसेट <> इसे लागू करता हूं।

ऐसा लगता है कि आकार प्रस्ताव (उम्मीद है) लागू होने के लिए कुछ समय इंतजार करना हमारी सबसे अच्छी शर्त हो सकती है। फिर आप सेट प्रकारों का प्रतिनिधित्व करने के लिए आकृतियों के किसी भी समूह का निर्माण करने में सक्षम होंगे जो आप चाहते थे, और कार्यान्वयन प्रदान करें ताकि मौजूदा सेट जैसे HashSet<T> उनके अनुरूप हों।

ऐसा करने के लिए एक सामुदायिक पुस्तकालय तब उभर सकता है, जिसमें सभी विभिन्न प्रकार के सेट (इंटेंशनल (भविष्यवाणी) और एक्सटेंशन (सूचीबद्ध), ऑर्डर किए गए, आंशिक रूप से ऑर्डर किए गए, अनियंत्रित, गणनीय, अनगिनत अनंत, बेशुमार अनंत, संभवतः गणितीय डोमेन भी शामिल हैं। , प्राकृतिक संख्याएँ आदि) विभिन्न आकृतियों के रूप में, इन सेटों के लिए और उनके बीच परिभाषित सभी संघ, प्रतिच्छेदन, कार्डिनैलिटी विधियों के साथ।

यह मुझे सड़क के नीचे 5 साल जैसा लगता है। एक साधारण परिवर्तन जिसे एक दिन में लागू किया जा सकता है, कुछ १०००x बड़ी गैर-निर्दिष्ट सुविधा की प्रतीक्षा क्यों करें जो शायद नहीं भी हो?

यह मुझे सड़क के नीचे 5 साल जैसा लगता है। एक साधारण परिवर्तन जिसे एक दिन में लागू किया जा सकता है, कुछ १०००x बड़ी गैर-निर्दिष्ट सुविधा की प्रतीक्षा क्यों करें जो शायद नहीं भी हो?

मैं सिर्फ IReadOnlySet<T> पर प्रगति की कमी का जवाब दे रहा हूं - यह मुद्दा पहले से ही 4 साल बाद खुला है।

Microsoft तरीका: सबसे सरल और उपयोगी चीज़ों में दशकों लग जाते हैं। यह दिमाग उड़ाने वाला है। 5 साल और गिनती।

और भी मज़ेदार बात यह है कि उनके पास यह यहाँ है
https://docs.microsoft.com/en-us/dotnet/api/microsoft.sqlserver.management.sdk.sfc.ireadonlyset-1

@terrajobst विचार?

• हम आम तौर पर मानते हैं कि यह वास्तव में हमारे इंटरफ़ेस पदानुक्रम में एक छेद है। हम केवल इंटरफ़ेस जोड़ने और मौजूदा सेट कार्यान्वयन पर इसे लागू करने पर ध्यान केंद्रित करने का सुझाव देते हैं। हम ISet<T> विस्तार IReadOnlySet<T> नहीं कर सकते (उसी कारण से हम अन्य परिवर्तनीय इंटरफेस के लिए नहीं कर सके)। हम बाद के चरण में ReadOnlySet<T> जोड़ सकते हैं। हमें दोबारा जांच करनी चाहिए कि IReadOnlySet<T> केवल ISet<T> से कम परिवर्तनशील एपीआई है।
• हमें IReadOnlySet<T> को ImmutableSortedSet<T> और ImmutableHashSet<T> (और उनके निर्माता) पर भी लागू करना चाहिए।
• हमें ISet<T> के अन्य कार्यान्वयन के लिए स्कैन करना चाहिए।

 namespace System.Collections.Generic {
+    public interface IReadOnlySet<out T> : IReadOnlyCollection<T>, IEnumerable, IEnumerable<T> {
+        bool Contains(T value);
+        bool IsProperSubsetOf(IEnumerable<T> other);
+        bool IsProperSupersetOf(IEnumerable<T> other);
+        bool IsSubsetOf(IEnumerable<T> other);
+        bool IsSupersetOf(IEnumerable<T> other);
+        bool Overlaps(IEnumerable<T> other);
+        bool SetEquals(IEnumerable<T> other);
+    }
-    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class HashSet<T> : ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
-    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T> {
+    public class SortedSet<T> : ICollection, ICollection<T>, IDeserializationCallback, IEnumerable, IEnumerable<T>, IReadOnlyCollection<T>, ISerializable, ISet<T>, IReadOnlySet<T> {
     }
 }

इसे करें! मैं आपको चुनौती देता हूं!

@terrajobst

हम ISet<T> विस्तार IReadOnlySet<T> नहीं कर सकते (उसी कारण से हम अन्य परिवर्तनीय इंटरफेस के लिए नहीं कर सके)।

क्या यह अभी भी डिफ़ॉल्ट इंटरफ़ेस विधियों के साथ भी सच है? क्या इसका मतलब है कि https://github.com/dotnet/corefx/issues/41409 बंद कर देना चाहिए?

@terrajobst

हम ISet<T> विस्तार IReadOnlySet<T> नहीं कर सकते (उसी कारण से हम अन्य परिवर्तनीय इंटरफेस के लिए नहीं कर सके)।

क्या यह अभी भी डिफ़ॉल्ट इंटरफ़ेस विधियों के साथ भी सच है? क्या इसका मतलब यह है कि dotnet/corefx#41409 बंद होना चाहिए?

हमने इस पर चर्चा की। हम सोचते थे कि डीआईएम काम करेगा , लेकिन जब हम समाधान पर चले तो हमने निष्कर्ष निकाला कि यह आमतौर पर एक शार्प डायमंड में परिणत होगा जिसके परिणामस्वरूप एक अस्पष्ट मैच होगा। हालाँकि, इसे हाल ही में चुनौती दी गई थी इसलिए मुझे लगता है कि मुझे इसे लिखना होगा और सुनिश्चित करना होगा कि यह वास्तव में काम कर रहा है या नहीं।

@terrajobst / @danmosemsft क्या किसी को इसे सौंपा गया है?

और, @terrajobst उस कार्य को स्पष्ट करने के लिए जिसे हम प्राप्त करना चाहते हैं:
```
हमें IReadOnlySet को भी लागू करना चाहिएअपरिवर्तनीय सॉर्टेडसेट परऔर अपरिवर्तनीय हैशसेट(और उनके निर्माता)
हमें आईसेट के अन्य कार्यान्वयन के लिए स्कैन करना चाहिए.
````
साथ ही हैशसेट, सॉर्टेडसेट पर उपरोक्त इंटरफेस को लागू करना।

स्कैनिंग बस कुछ भी ढूंढती है और अगर यह संदिग्ध लगती है तो इसे लाएं।

अगर यह अभी भी पकड़ने के लिए तैयार है तो मुझे दिलचस्पी होगी

@Jlalond नहीं , आपको सौंपा गया है। प्रस्ताव के लिए धन्यवाद।

@danmosemsft @terrajobst
बस एक अपडेट। मैं इस पर काम कर रहा हूं, इंटरफेस को निजी कोर लिब में जोड़ा, बस इस पर संग्रह.जेनेरिक और अपरिवर्तनीय पिक अप के माध्यम से अपना रास्ता ठोकर खा रहा है।

अंतिम प्रश्न यदि आप अपने सिर डैन को जानते हैं, तो क्या मुझे इसके लिए मोनो में कोई बदलाव करने की आवश्यकता है? मैं इस बारे में व्यावहारिक नहीं हूं कि कोरएफएक्स कहां समाप्त होता है और मोनो शुरू होता है। तो अगर आप जानते हैं कि यह मुझे कुछ स्वतंत्र शोध से बचा सकता है

@ जलालॉन्ड आपको मोनो में बदलाव करने की आवश्यकता नहीं है। मोनो रनटाइम को इस रेपो में ले जाने का कारण यह है कि कोरसीएलआर या मोनो रनटाइम के साथ समान सटीक पुस्तकालयों का उपयोग करना सहज बनाना है। कोर लाइब्रेरी का केवल एक छोटा सा हिस्सा है जो अलग हो जाता है:
coreclrsrcSystem.Private.CoreLib बनाम mononetcoreSystem.Private.CoreLib। (अधिकांश मुख्य पुस्तकालय पुस्तकालयों से बाहर साझा किए जाते हैं। सिस्टम। निजी। कोरलिब)। इसलिए जब तक आप उसे स्पर्श नहीं करते - आप प्रभावित नहीं होते।

@danmosemsft स्पष्टीकरण के लिए धन्यवाद, मुझे आशा है कि यह शीघ्र ही किया जाएगा।

अरे @danmosemsft बस इस पर फॉलो अप करें। CoreLib src असेंबली में निर्माण कर रहा है, मैं संदर्भित परिवर्तन देख सकता हूं। हालांकि रेफरी असेंबली किसी भी बदलाव का पता नहीं लगा रही है। यह सब मुझे पकड़ रहा है, लेकिन मुझे दस्तावेज़ों में कोई जानकारी नहीं मिल रही है। कोई भी व्यक्ति या संकेत जो आप मुझे दे सकते हैं ताकि मैं इसे पूरा कर सकूं (मेरा मतलब है, 5 साल बाद)

#32488 . द्वारा संबोधित