ألن يكون لطيفًا إذا كان لدينا فقط بعض التركيبات اللغوية لجعل الأشياء غير قابلة للتغيير؟ ثم لن نضطر إلى الحصول على هذه الواجهات السحرية.

whoisj أي لغة؟ لدى CLR العشرات منهم.

حتى كميزة لغوية محتملة ، فإنها تتطلب تمثيل البيانات الوصفية. في هذه الحالة ، تكون واجهة العلامة (أو الواجهة السلوكية) جيدة مثل أي واجهة أخرى. محاولة نقل ثبات نوع المجموعة من خلال إدخال بيانات وصفية جديد لا يبدو مناسبًا لأن CLR لا ينبغي أن يضع افتراضات حول كيفية عمل فئة عشوائية داخليًا (وليس لدى CLR أي مفهوم لفئات المجموعة على الإطلاق جانباً من أجل المصفوفات).

whoisj أعتقد أن هذا يعتبر على الأقل لإحدى إصدارات C # المستقبلية. لكن هذا القرار لا يؤثر على الحاجة إلى واجهات متناظرة عبر جميع المجموعات. علاوة على ذلك ، يمكنني تخيل سيناريوهات حيث يمكن أن تكون قائمة العناصر القابلة للتغيير للقراءة فقط مفيدة ، على سبيل المثال في الألعاب التي تهتم بجودة الكود والأداء.

تتوفر أيضًا مجموعات غير قابلة للتغيير:

https://msdn.microsoft.com/en-us/library/system.collections.immutable (v = مقابل 111) .aspx

لتحقيق مجموعة غير قابلة للتغيير تمامًا ، نحتاج فقط إلى طريقة لتعريف immutable T ثم استخدامها للإعلان عن مجموعة Immutable...<T> .

HaloFour لقد قطعنا هذا الطريق من قبل: ابتسامة متكلفة: ولكني ما زلت أعتقد أن CLR بحاجة إلى طريقة للقول "ها هو مقبض ، اقرأ منه ولكن كل الإجراءات التي تسبب أي نوع من الكتابة من خلاله ستفشل ؛ أوه وهذا الثبات معدي ، لذا فإن أي مقبض يتم الوصول إليه من المقبض الثابت يكون أيضًا غير قابل للتغيير (بما في ذلك this ) ".

dsaf بالتأكيد ! في قضية أخرى ، اقترحت أن يكون لدينا مصطلح مضاد قابل للكتابة للقراءة فقط لتمكين استخدام مجموعة للقراءة فقط من العناصر القابلة للكتابة. شيء على غرار readonly Bag<writable Element> .

لقد اقترحت أن يتم التعامل مع أي مرجع تم تمييزه بـ & على أنه غير قابل للتغيير من قبل المترجم. ما زلت أشعر أنه يحتاج فقط إلى فحص وقت التجميع ، ويجب بالضرورة أن يتم فرضه بواسطة CLR نفسه لأنني في الغالب أسعى إلى التحقق من وقت التجميع للمنطق وليس ضمانات وقت التشغيل. سيغطي هذا أي مرجع يريد المطورون أن يكون غير قابل للتغيير ، ولكن على أساس كل مكالمة.

whoisj ربما ، لكن هذا عرضي إلى حد ما وهو يحول هذا الطلب من شيء يمكن لـ dsaf أن يتفرع / العلاقات العامة بعد ظهر هذا اليوم إلى شيء يتطلب جهدًا عبر ثلاثة فرق مختلفة.

أنت أيضًا تتعامل مع هذا على أنه مصدر قلق للمترجم. في هذه المرحلة ، لا يوجد مترجم متورط (بخلاف مترجم JIT) ويمكن للمدقق فقط محاولة منع تنفيذ التعليمات البرمجية "غير الملائمة". حتى آليات التشغيل الحالية للثبات ، حقول initonly ، يمكن هزيمتها بسهولة إذا تم تخطي التحقق (أو عبر الانعكاس).

أوافق على أنه سيكون من الجيد لو أن لغة C # والمجمع يمكن أن يكون لهما دعم أفضل للطرق "الخالصة". السمة PureAttribute موجودة بالفعل ولكنها تُستخدم بشكل متقطع ولا يوجد في الحقيقة أي دعم لغوي لها. وحتى إذا كانت C # تدعمها من خلال أخطاء المترجم (يمكن فقط استدعاء pure ، وما إلى ذلك) ، فمن السهل جدًا هزيمتها باستخدام لغة مختلفة. لكن هذه الطرق يجب أن تعلن عن نفسها وأن تفرض نفسها كما تم تجميعها مرة واحدة إلى IL ، كل الرهانات متوقفة أساسًا ولا يمكن لأي من المجمعين ثني كيفية تنفيذ التجميع الحالي.

تضمين التغريدة

بافتراض أنه ليس لدينا طريقة عامة لدعم المراجع "الخالصة" أو "الثابتة" ، فأنا أفترض أن المقترح هو البديل الأفضل.

إذا كنت بحاجة إليها الآن ، فإن مكتبة كومنز الخاصة بي (Commons.Collections https://github.com/yanggujun/commonsfornet/tree/master/src/Commons.Collections/Set) لديها دعم محدد للقراءة فقط. يرجى من المسؤول حذف هذا المنشور إذا كان يعتقد أنه إعلان ... اقتراحي هو البحث عن بعض التطبيقات مفتوحة المصدر.

yanggujun شكرًا لك على الاقتراح ، الذي يبدو وكأنه مكتبة جميلة ، لكنني سأقوم بتدوير مكتبي لتجنب التبعيات الإضافية.

اقتراحي هو البحث عن بعض التطبيقات مفتوحة المصدر.

هذا حل بديل ، يجب أن تكون الواجهات الأساسية مثل IReadOnlySet جزءًا من .NET Framework نفسه.

هل هذا يحتاج إلى سبيليت ليصبح "جاهزًا لمراجعة واجهة برمجة التطبيقات"؟

وأثناء وجودنا فيه ، فكر في تسميته بشيء مختلف عن "ReadOnly" (انظر المنشور المثير للاهتمام: http://stackoverflow.com/questions/15262981/why-does-listt-implement-ireadonlylistt-in-net-4- 5)
"مقروءة" تبدو جيدة.

GiottoVerducci No. أفضل الاحتفاظ بنمط تسمية ثابت حتى لو كان غير كامل. أنت حر في إثارة قضية منفصلة لإعادة تسمية الواجهات الحالية بالرغم من ذلك.

تصميم API المقترح:

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 بينما لا تزال تجريبية.
أعتقد أن هذه حالة استخدام شائعة جدًا ويجب التعامل معها في libs القياسية.

هل هناك المزيد من العمل الذي يتعين القيام به على واجهة برمجة التطبيقات هنا ، كما تقترح العلامة؟ يسعدني قضاء بعض الوقت في هذا الأمر إذا كان مفيدًا ويمكن لأي شخص تحديد ما هو مطلوب.

APIashmind المقترح يبدو رائعًا.

هل يمكن إجراء ISet<T> لتمديد IReadOnlySet<T> ؟ لم يحدث هذا IList<T> / IReadOnlyList<T> ؟

إذا لم يكن الأمر كذلك ، أفترض أن التغييرات الأخرى التي يجب مراعاتها هي إضافة IReadOnlySet<T> إلى قائمة الواجهة لجميع تطبيقات ISet<T> في corefx بما في ذلك HashSet<T> و SortedSet<T> و نظراء غير قابلة للتغيير في System.Collections.Immutable .

يجب أن أتفق مع GiottoVerducci . استخدام اسم مثل IReadOnlySet<T> لا يعلن عن إمكانيات العقود ، بل يعلن عن قيود العقود. ومن ثم ، فإن استخدام نفس العقد جنبًا إلى جنب مع عقد آخر يتعارض مع تلك القيود أمر محير. أعتقد أن اسم العقد يجب أن يصف تأكيدًا إيجابيًا يتعلق بما يدعمه المنفذ. اسم مثل IReadableSet<T> ليس رائعًا ، باعتراف الجميع ، لكنه على الأقل يصف بشكل أفضل ما يفعله المنفذ.

HaloFour أوافق من حيث المبدأ ، لكن لدينا نفس الموقف الآن مع IReadOnlyList<T> . الحفاظ على الاتساق يتفوق على الزيادة في الدقة هنا ، IMHO.

تضمين التغريدة

أنا أفهم ، والاتساق مهم. أعتقد أن هذا يجيب أيضًا عن سبب عدم تمديد IReadOnlySet<T> ISet<T> IReadOnlySet<T> .

الحفاظ على الاتساق يتفوق على الزيادة في الدقة هنا ، IMHO.

أعتقد أن هذا يجيب أيضًا عن سبب عدم تمديد IReadOnlySet<T> ISet<T> IReadOnlySet<T> .

أعتقد أنك تفتقد النقطة. هذا هو السبب في أنه يجب أيضًا إصلاح IList<T> ، ICollection<T> ، IDictionary<TKey, TValue> ، بالإضافة إلى ISet<T> ، لتنفيذ واجهات العرض للقراءة فقط. وإلا فسيظل الجميع في حيرة من أمرهم عند العمل حول التصميم غير البديهي لـ BCL .

تضمين التغريدة

أنا لا أعارض. ما لا يعجبني في ذلك هو وجود عقد ينص على تمديد سلوك القراءة فقط بموجب عقد ينص على سلوك القراءة والكتابة. التسمية خاطئة والتكوين خاطئ. لكن ها نحن ذا. أرغب في التصويت لتغيير كليهما ، لكنني أشك في أن يكون هذا على الطاولة.

تضمين التغريدة

عندما تحصل على واجهة في شيء ما ، فإنها _ view_ في شيء ما. طريقة العرض نفسها _is_ للقراءة فقط. بافتراض أنك كتبت رمزًا آمنًا للكتابة ولن تتنقل في التنبيه ، إذا تلقيت شيئًا للقراءة فقط ، فهو ، لجميع المقاصد والأغراض ، للقراءة فقط. هذا ليس ضمانًا بأن البيانات لن تتغير. إنه مثل فتح ملف للقراءة فقط. يمكن تغيير ملف مفتوح للقراءة فقط من خلال عملية أخرى. أو مثل الوصول للقراءة فقط إلى الصفحات على موقع ويب حيث يكون للمسؤول عرض للقراءة والكتابة في البيانات ويمكنه تغييرها من تحتك.

لست متأكدًا من سبب اعتبار مصطلح "للقراءة فقط" خطأ هنا. للقراءة فقط _not_ تعني أنه غير قابل للتغيير. هناك حزمة nuget كاملة / واجهة برمجة تطبيقات مختلفة (حيث تولد الإضافة / الإزالة كائنًا جديدًا ويضمن المثيل الحالي ألا يتغير أبدًا - وبالتالي يكون غير قابل للتغيير) لذلك إذا كان هذا هو ما تحتاجه.

كنت أفكر شيئا مماثلا. يعد "للقراءة فقط" في .NET ضمانًا ضعيفًا جدًا للحقول أيضًا. بالنظر إلى التمرين ، أنا متأكد من أن كل هذا سيكون أكثر منطقية. في الوقت الحالي ، من الجدير أن تكون براغماتيًا.

لذلك بشكل عام ، إذا قبلت طريقة ما IReadOnlySomething<T> يمكنك ، بشكل عام ، افتراض أنها لن تقوم بتعديلها. ليس هناك ما يضمن أن طريقة الاستلام لن تؤدي إلى تنشيط المرجع ، وليس هناك ما يضمن أن تنفيذ الواجهة لن يعدل نفسه داخليًا عند الوصول إليه أيضًا.

في C ++ ، يضعف const_cast ضمانات const أيضًا ، وهو أمر مخزٍ (خاصة في الوقت الحاضر مع المُعدِّل mutable ) ولكن في الممارسة العملية لا ينتقص من مدى الفائدة const كميزة. عليك فقط أن تعرف ما الذي تتعامل معه.

binki يميز بشكل جيد. _Immutable_ في الاسم يعني ضمانة قوية للاستقرار بمرور الوقت لجميع المعنيين.

هل لديها مصدر موثوق لماذا IList<T> لا تمتد IReadOnlyList<T> ؟

تضمين التغريدة

الواجهة ليست طريقة عرض ، إنها عقد. هذا العقد يعلن عن قدرات المنفذ. إذا لم يقم المنفذ بتنفيذ هذه القدرات فعليًا ، فسأعتبر ذلك انتهاكًا للعقد. تدعي فئة List<T> أنها "is-a" IReadOnlyList<T> ، لكنها ليست كذلك. إنها تفتقر إلى تلك القدرة.

هناك مدارس فكرية متعددة حول هذا الموضوع. من الواضح أنني أنتمي إلى المدرسة حيث يتبع توريث الواجهة بشكل صارم علاقات "is-a" بين الأنواع. أنا بالتأكيد أؤيد نهجًا أكثر دقة للتكوين مع الواجهات وأعتقد أن List<T> وأقاربه يمكن أن يستفيدوا على الأرجح من تنفيذ حوالي 3-4 واجهات إضافية (قراءة ، كتابة ، إلحاق ، إلخ.) لكنني أعتقد بالتأكيد أن يجب أن يصف اسم الواجهة ما يمكن أن يفعله النوع وليس ما لا يمكن أن يفعله. تأكيدات القدرة السلبية ليس لها معنى كبير بالنسبة للعقود.

تضمين التغريدة

في الوقت الحالي ، من الجدير أن تكون براغماتيًا.

أنا موافق. ونحن على ما نحن فيه. إذا تم تغيير IList<T> لتمديد IReadOnlyList<T> فمن المنطقي أن يتم تغيير ISet<T> لتمديد IReadOnlySet<T> ، إلخ.

هل من الزائدة عن الحاجة أيضًا الدفع مقابل واجهات IReadableX<T> ، IWritableX<T> ، إلخ. للعيش بجانب IReadOnlyX<T> ؟

هل لدى أي شخص مصدر موثوق يفسر سبب عدم قيام IList<T> بتمديد IReadOnlyList<T> ؟

من الواضح أنه سيكون تغييرًا يكسر ABI عند تحميل التجميعات التي تم تجميعها مقابل أطر عمل شبكة قديمة. لأنه عند تنفيذ الواجهة ، فإن معظم المجمعين سينشئون تلقائيًا تطبيقات واضحة للواجهة عندما تعتمد التعليمات البرمجية المصدر على تنفيذ الواجهة الضمني ، إذا قمت بتجميع فصلك بتطبيق 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

أعتقد أنه من المثالي ألا تأخذ أي طريقة مقارنات.

فقط للتوضيح ، أردت أن أقول إنه يجب أن يعرض المقارنة ، لا أن يأخذ واحدًا. نظرًا لأن كل مجموعة أو قاموس يجب أن تحتوي على بعض خوارزمية المساواة ، فقد يكون هذا قد تم كشفه على الواجهة. لكنني لا أتذكر حالة الاستخدام الخاصة بي لذلك الآن - شيء مثل إنشاء مجموعة باستخدام نفس المقارنة كما في حالة مقدمة خارجيًا.

بينما تثير هذه المناقشة الكثير من النقاط المثيرة للاهتمام ، يبدو أنها تبتعد كثيرًا عن الاقتراح البسيط والواضح الذي بدأ هذا الموضوع. وهذا أمر محبط لأنني أرغب حقًا في معالجة هذه المشكلة.

كما قال OP ، فإن الفشل في الحفاظ على التكافؤ بين أنواع المجموعات عندما تمت إضافة IReadOnlyList بدون IReadOnlySet أمر مؤسف وقام العديد من الأشخاص بتطبيق إصداراتهم الخاصة من واجهة IReadOnlySet كحل بديل (لدى فريقي حل بديل مماثل). واجهات الحل هذه ليست مثالية لأن فئات corefx لا يمكنها تنفيذها. هذا هو السبب الرئيسي لتوفير هذا في إطار العمل: إذا كان لدي HashSet ، أود أن أتمكن من استخدامه كمجموعة IReadOnlySet دون نسخ أو تغليف الكائن الذي أملكه بالفعل. للأداء على الأقل هذا غالبًا ما يكون مرغوبًا.

يجب أن يكون اسم الواجهة بوضوح IReadOnlySet. يتفوق الاتساق على أي مخاوف تتعلق بأسماء IReadOnlyXXX. لقد أبحرت السفينة.

لا يمكن تغيير أي من الواجهات الموجودة (IReadOnlyCollection). لا تسمح متطلبات التوافق الخلفي لـ .NET بإجراء تغييرات من هذا القبيل. من المؤسف أن المقارنات غير مكشوفة في واجهات IReadOnlyXXX الحالية (لقد واجهت هذا أيضًا) ولكن مرة أخرى أبحرت السفينة.

السؤال الوحيد الذي يبدو أنه يبقى من وجهة نظر عملية هو بين هذين التعريفين المحتملين للواجهة.

تم اقتراحه مسبقًا بواسطة

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 الأخرى.

@ aaron-meyers القلق الوحيد الذي سأشعر به هو أن IsSubsetOf والأصدقاء لا يمكن اشتقاقهم من Contains بطريقة _ فعالة. عندما يكون هناك جدولا تجزئة ، على سبيل المثال ، فإن الاعتماد على Contains يفرض على التطبيق استخدام حلقات متداخلة بدلاً من مطابقة التجزئة.

ربما تحتوي الواجهة الجديدة IComparableSet<T> على العمليات المحددة.

لدينا بالفعل طرق تمديد على IEnumerable<T> لعدد قليل من العمليات المحددة.

@ jnm2 يتطلب تنفيذ هذه الأساليب المستخدمة بواسطة HashSet فقط احتواء وتعداد المجموعة الأخرى (التي سيحصل عليها IReadOnlySet من خلال وراثة IReadOnlyCollection). لا يتطلب الأمر على الرغم من معرفة أن المجموعة الأخرى تستخدم نفس المقارنة. ربما يجدر إضافة الخاصية Comparer إلى 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 framework القادمة؟

متى سيصل هذا العمل؟ أي جداول زمنية؟

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);
}

ولا شيء أكثر. يمكن دائمًا إضافة المزيد من واجهة برمجة التطبيقات في المستقبل ، إذا كانت هناك حاجة إلى ذلك. ولكن لا يمكن إزالته ، وبالتالي هذا الاقتراح.

ثم نضيف هذه الواجهة إلى قائمة الواجهات الممتدة بمقدار ISet<T> .

من الوثائق

ISet<T> : توفر هذه الواجهة طرقًا لتنفيذ المجموعات ، وهي مجموعات تحتوي على عناصر فريدة وعمليات محددة. هاشستو SortedSetمجموعات تنفيذ هذه الواجهة.

من الكود

تحتوي الواجهة 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>

تغيير تافه ، القليل للمناقشة ، فائدة كبيرة.

من فضلك دعنا نحقق ذلك. اسمحوا لي أن أعرف ما إذا كان سيتم قبول طلب السحب هذا ودمجها. يمكنني إنشاؤه بعد ذلك.

karelzterrajobstsafernianhays

لقد وجدت هذه المناقشة عند العمل على مشكلة في العالم الحقيقي حيث أردت استخدام مجموعة المفاتيح لقاموس لعمليات القراءة فقط المحددة. لدعم هذه الحالة ، إليك واجهة برمجة التطبيقات التي أقترحها.

المنطق

API المقترحة

 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 s مثل SortedDictionary أو ImmutableDictionary ؟

التحديثات

• تمت إزالة TryGetValue لأنه ليس في ISet<T> وبالتالي من المحتمل أن يمنع إعادة التعيين على الإطلاق ISet<T> لتنفيذ IReadOnlySet<T> .
• تمت إضافة فئة ReadOnlySet<T> التي تشبه ReadOnlyCollection<T> .

TylerBrinkley شكرا لإضافة اقتراح API في الموضوع. هل تمانع في إضافة الأسباب المنطقية وحالات الاستخدام؟ حتى أتمكن من وضع علامة عليه جاهزًا للمراجعة والسماح لخبراء واجهة برمجة التطبيقات باتخاذ القرار؟

لا تنسَ TylerBrinkley تضمين خاصية EqualityComparer في IReadOnlySetواجهه المستخدم. يتم فقدانها حاليًا في القواميس والمجموعات في CoreFX ، لكنها مشكلة.

dmitriyse ما فائدة الحصول على خاصية IEqualityComparer<T> فقط؟ ماذا ستفعل به؟

يجب أن تبلغ القواميس والمجموعات عن EqualityComparers الخاصة بهم للسماح باستنساخ المجموعة الصحيح.
لسوء الحظ لقد نسيت أين تمت مناقشة هذه المشكلة.

إذا كنت تقوم بالاستنساخ ، ألن تعمل باستخدام نوع خرساني؟ لماذا تحتاج الواجهة إلى دعم IEqualityComparer<T> ؟

على سبيل المثال ، إذا قمت بتعيين السلاسل ومقارن مساواة حالة الأحرف ، فستتلقى استثناءً عند إنشاء HashSet جديد بدون تحديد EqualityComparer الصحيح. هناك حالات لا يمكنك فيها معرفة استخدام EqualityComparer في المجموعة المحددة.

إنه ليس مجرد استنساخ. أعتقد أن السيناريو الأكثر شيوعًا هو مقارنة مجموعتين - أحتاج إلى معرفة أنهما يستخدمان نفس المقارنة من أجل تنفيذ مقارنة مثالية باستخدام يحتوي على. أعتقد أن هناك مثالاً في هذا الموضوع.

ومع ذلك ، فإنني أفضل أن يكون IReadOnlySet باستخدام طريقة "يحتوي" فقط بدلاً من عدمه على الإطلاق. سيكون من الجيد أن تكون قادرًا على تنفيذ مقارنة المجموعة بشكل عام ولكن ليس شائعًا مثل مجرد الحاجة إلى مرجع للقراءة فقط للمجموعة.

احصل على Outlook لنظام التشغيل iOS https://aka.ms/o0ukef

من: Tyler Brinkley [email protected]
تاريخ الإرسال: الخميس 10 مايو 2018 6:21:52 صباحًا
إلى: dotnet / corefx
نسخة إلى: آرون مايرز ؛ يذكر
الموضوع: Re: [dotnet / corefx] الرجاء إضافة واجهة IReadOnlySet وجعل HashSet ، SortedSet ينفذها (# 1973)

إذا كنت تقوم بالاستنساخ ، ألن تعمل باستخدام نوع خرساني؟ لماذا تحتاج الواجهة إلى دعم IEqualityComparer.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، واعرضها على GitHub https://eur01.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fdotnet٪2Fcorefx٪2Fissues٪2F1973٪23issuecomment-388051258&data=02 ٪ 7C01٪ 7C٪ 7Cc45ea16cd3034ddd69d808d5b678ff33٪ 7C84df9e7fe9f640afb435aaaaaaaaaaaa٪ 7C1٪ 7C0٪ 7C636615553141417289 وsdata = xRI27JtyaAwnZ2anY05oTlxmPY5AaGVl٪ 2BRdXK2uR0٪ 2F8٪ 3D & محفوظة = 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٪ 3D & محفوظة = 0 .

أوافق - الطريقة الوحيدة التي يمكنك من خلالها معرفة أنواع التكرارات التي قد تجدها في المجموعة (حساسة لحالة الأحرف ، وغير حساسة لحالة الأحرف ، وما إلى ذلك) هي من خلال تعريض المقارنة.

بدأت أعتقد أن اقتراحي لن يتم قبوله لأن إضافة كل هذه الأساليب إلى Dictionary<TKey, TValue>.KeyCollection سيكون لها تكلفة كبيرة لحجم الكود. راجع هذه المناقشة بخصوص إضافة واجهة برمجة تطبيقات جديدة لأنواع عامة يتم إنشاء مثيل لها بشكل شائع.

لا أعتقد أنك ستكون قادرًا على وضع مقارنة على IReadOnlySet .

يأخذ SortedSet IComparer ، بينما يأخذ HashSet IEqualityComparer .

نقطة جيدة ، يمكن اعتبار المقارنة بمثابة تفاصيل تنفيذ لا تنتمي إلى واجهة عامة.

احصل على Outlook لنظام التشغيل iOS https://aka.ms/o0ukef

من: Cory Nelson [email protected]
تاريخ الإرسال: الخميس ، 10 مايو 2018 ، الساعة 5:04:06 مساءً
إلى: dotnet / corefx
نسخة إلى: آرون مايرز ؛ يذكر
الموضوع: Re: [dotnet / corefx] الرجاء إضافة واجهة IReadOnlySet وجعل HashSet ، SortedSet ينفذها (# 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٪ 3D & محفوظة = 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٪ 3D & محفوظة = 0 .

قد يكون هناك بعض القيمة في إضافة واجهات IUnorderedSet و IOrderedSet ، لكنني لا أريد أن يعرقل ذلك دفع IReadOnlySet خلاله.

أحب اقتراحpgolebiowski ولكني سأجعل هذه الواجهة أكثر أساسية.

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

هذا بعد ذلك مناسب للمجموعات غير المعدودة مثل الفترات (الحقيقية) أيضًا. بين ذلك و IReadOnlySet يمكنك احتواء بعض الواجهات الأخرى مثل ICountableSet (الملقب IEnumerableSet ) ، IUnorderedSet و IOrderedSet .

لكن توافق على أن IReadOnlySet سيكون بمثابة تحسن كبير عما هو متاح حاليًا.

+1 لـ @ نيكريدوود

لقد كان مفتوحًا لأكثر من 3 سنوات حتى الآن. يرجى جعل هذا يحدث عن طريق تغيير النهج. يتيح تقديم التغيير الذي ذكره NickRedwood جميع التحسينات الأخرى التي تناقشها في هذا الموضوع. تتفق جميع المناهج حول هذا الشيء الوحيد التافه. لذلك دعونا نضيف هذا الشيء الوحيد التافه الذي يعتبر أساسيًا ثم نخلق مشكلة أخرى للتحسينات المحتملة التي تكون جميعها اختيارية.

TylerBrinkleysafernkarelzterrajobst

لا أرى حقًا فائدة كبيرة لواجهة IReadOnlySet<T> باستخدام طريقة Contains . على الرغم من أن هذه الطريقة مفيدة ، إلا أنها مدرجة بالفعل في واجهة ICollection<T> والتي تحتوي أيضًا على خاصية IsReadOnly تهدف إلى توضيح ما إذا كانت طرق التعديل الخاصة بـ ICollection<T> مدعومة أم لا. ما عليك سوى تنفيذ ICollection<T> وحقق عائد true IsReadOnly true . الوظيفة الأخرى الوحيدة التي من المتوقع أن تدعمها ستكون خاصية Count ، كونها قابلة للتعداد ، وطريقة CopyTo التي لا تبدو محدودة للغاية.

سأكون سعيدًا جدًا لتطبيق IReadOnlySet<T> المقترح على أساس IReadOnlyCollection<T> - سيكون تحسينًا كبيرًا لما هو متاح حاليًا. ( TylerBrinkley - افترض أنك تقصد IReadOnlyCollection<T> بدلاً من ICollection<T> .

أعتقد أنني أخطأ في جانب واجهات أكثر أساسية ، وإذا كان هناك واجهة لـ Set ، فستكون واجهة أحادية الأسلوب باستخدام طريقة Contains . لها أساس رياضي جيد وهي نظيفة للغاية. ومع ذلك ، عند التعديل التحديثي للفئات الحالية ، فأنا أوافق على أن التعديل التحديثي الأقل هو الأفضل ، وإذا كان هناك واجهة واحدة فقط تم تعديلها ، فيجب أن تكون IReadOnlySet<T> على أساس IReadOnlyCollection<T> .

IReadOnlyCollection<> على .Contains لأن ذلك سيمنعه من أن يكون متغيرًا.

نقطة جيدة ولقد قمت بتصحيح رسالتي السابقة لتكون متناقضة. يجب أن يكون 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) عليه.

@ jnm2 يقول:

IReadOnlyCollection<> على .Contains لأن ذلك سيمنعه من أن يكون متغيرًا.

يبدو أن هذه هي أكبر مشكلة بالنسبة لي في الوقت الحالي. سيكون من الغريب أن يكون IReadOnlySet<T> ثابتًا عندما يكون IReadOnlyCollection<T> متغيرًا. يبدو أن العديد من واجهات IReadOnly* تم تصميمها بعناية لتكون out T مع كون الواجهات القابلة للكتابة ثابتة بالضرورة. يرغب معظمنا في أن يعلن على الأقل عن طريقة Contains(T) IReadOnlySet<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);
}

إنه الجزء المشترك الوحيد من التصميم الذي يبدو أن الجميع قادرون على الموافقة عليه.

أقول أننا الآن أنهينا التصميم هنا. إذا كنت ترغب في تمديده في المستقبل ، فافعل ذلك في مشكلة مختلفة. هذه هي الوظيفة الأكثر أهمية التي يجب أن تكون في prod.

من هو مع من ضد؟

أحب اقتراح ashmind . سيكون من الرائع أن يتمكن Dictionary.Keys من تنفيذ هذه الواجهة لأنها تقنيًا IReadOnlySet<TKey> .

هل يمكنك وضع علامة على هذا كـ api-ready-for-review ؟ لقد وجدت نفسي بحاجة إلى هذه الواجهة مرة أخرى وما زالت غير موجودة.

لماذا لم يتم تنفيذ هذا بعد؟

[تحرير] اعتذار - كان ردي الأصلي مختلطًا بواجهة برمجة تطبيقات أخرى. ليس لدي رأي قوي حول هذا النص ، تم تحرير النص. آسف للارتباك!

لماذا لم يتم تنفيذ هذا بعد؟

واجهة برمجة التطبيقات (API) لم تلفت انتباه مالكي المنطقة حتى الآن -safern. لست متأكدًا من ارتفاعه في قائمة أولويات المجموعات. عدد التصويت الإيجابي مرتفع إلى حد ما.
الحقيقة هي أننا نقوم الآن بإغلاق NET Core 3.0 ، لذلك سيتعين عليها انتظار الإصدار التالي على الأقل لأنه ليس مهمًا لـ 3.0.

أنا مندهش أيضًا من أن هذا لم يتم توفيره خارج الصندوق.

يمكن أن تساعد هياكل البيانات غير القابلة للتغيير بشكل كبير في تحسين قابلية صيانة الكود ، ولكن يصعب استخدامها بدون واجهة في المكتبات القياسية التي تحدد الدلالات وتسمح للتطبيقات المختلفة بالعمل معًا.

بدون هذا ، فإن كل مكتبة تعني استخدام مجموعة غير قابلة للتغيير كمعامل / قيمة عودة تحتاج إلى اللجوء إما إلى استخدام IEnumerable وهو أقل كفاءة وغير صحيح من الناحية اللغوية أو استخدام واجهات / فئات خاصة بهم في توقيعاتهم التي لا تتوافق مع أي شخص آخر.

أشعر بالفضول لمعرفة ما إذا كانت هناك أي حلول فعالة من حيث عمليات البحث عن Contains وتجنب تحديد النوع الملموس للمعامل / قيمة الإرجاع. أفضل ما يمكن أن أفكر فيه من أعلى رأسي هو استخدام IEnumerable في التوقيع وتمرير مفاتيح ReadOnlyDictionary. ولكن هذا يبدو سيئًا بعض الشيء ، خاصة في المكتبة. نظرًا لأن Enumerable.Contains في Linq سيستخدم تنفيذ مجموعة Contains ، يجب أن يكون هذا فعالاً أثناء التوافق ، لكنه لا ينقل النية التي قد تؤدي إلى استخدام تطبيقات أقل أداءً.

@ adamt06 أنت تبحث عن ISet<T> .

scalablecory أنت على حق ، مع تنفيذ غير قابل للتغيير ، وهناك واحد: ImmutableHashSet<T>

لا أحد يعرف / يفهم لماذا ICollectionلا يمدد IReadOnlyCollection؟؟
اعتقدت أن هذا كان مرتبطًا قليلاً بهذا الموضوع. بدلا من فتح موضوع جديد. ربما أنا مجرد سوء فهم شيء ما.

فكرة أخرى ، لكنها خارج الموضوع تمامًا ، ولماذا لا تمتلك 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>
لماذا يجب ألا تكون مجموعة القراءة / الكتابة امتدادًا لمجموعة للقراءة فقط؟

تضمين التغريدة

نعم. ولكن لا يزال أيضًا لا يرى 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 "ICollection"ثابت في ICollection، شكرًا للإشارة إلى الخطأ المطبعي ..
DotNetStandard i net461. وهذا هو المكان الذي يجب أن يكون عليه التغيير. netstandard 2+

سأكرر ...
لماذا يجب ألا تكون مجموعة القراءة / الكتابة امتدادًا لمجموعة للقراءة فقط؟

ولماذا يجب على المرء أن يلقي مجموعة على سبيل المثال "ToArray ()" فقط لفضح أقل إذا كانت؟

ولأنه يمكنك إضافة واجهات جديدة في الإصدارات الأعلى دون كسر الأشياء. تم تنفيذ طرق الجمع الخاصة بـ IReadOnlyCollection بالفعل. ملاحظة يجب كسر ، ...: - /

@ Genik0 يبدو أنه لن يكسر توافق المصدر وهو ما كنت تفكر فيه [لم تكن تفكر ؛ ] ، لكنه سيؤدي إلى كسر التوافق الثنائي الذي يعمل مع جداول IL ، وليس C #.

طيب @ jnm2 شكرا.
سأتوقف عن التشدق في الموضوع الآن ، فقط أعتقد أنه هندسة سيئة. شكرا للجميع على الاستماع / شرح :-)

@ jnm2

@ Genik0 يبدو أنه لن يكسر توافق المصدر وهو ما تفكر فيه ، ولكنه قد يكسر التوافق الثنائي الذي يعمل مع جداول IL ، وليس C #.

إلى nitpick (معذرة) ، سيؤدي أيضًا إلى تعطيل توافق المصدر إذا قام المصدر الخاص بك بتنفيذ ICollection<T> من قبل .net-4.5. سيبدأ الفصل في فشل التحويل البرمجي بسبب الفشل في التنفيذ الصريح لـ IReadOnlyCollection<T>.Count . لكن التوافق الثنائي يمثل صفقة أكبر لأنه سيمنعك من استهداف مجموعة واسعة من إصدارات .net (يجب أن يكون لديك ثنائيات مختلفة للتشغيل على ≥.net-4.5 عن <.net-2 بغض النظر عما تريد يجب أن تستهدف كليهما بدلاً من مجرد استهداف إطار العمل القديم).

أتساءل عما إذا كان مع إضافة دعم تنفيذ الواجهة الافتراضية في C # 8 إذا كان ICollection<T> يمكن أن ينفذ IReadOnlyCollection<T> لـ .NET Core 3.0+.

ربما هناك حاجة إلى ملحق ، ثم هو atleat نفس المجموعة. على سبيل المثال ، إذا كنت بحاجة إلى الحصول على مجموعة لا تعد ولا تحصى أو مجموعة مجمعة لمجموعات لا تعد ولا تحصى ... أية أفكار؟

[تم التعديل بواسطة تعليق @ 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 بدلاً من استدعاء هذه الطريقة؟

@ jnm2 omg. انت على حق. أحيانًا لا ترى الصورة الواضحة وتفرط في تعقيد الأمور !!!

ما زلت أسمي الامتداد ، فقط للحصول على البساطة ؛-)
بفضل الزميل....

ما هي الحالة هنا؟ أود حقًا هذه الواجهة في lib القياسي ولديها HashSet <> لتطبيقها.

يبدو أن أفضل رهان لدينا قد يكون الانتظار لفترة أطول حتى يتم (نأمل) تنفيذ اقتراح الأشكال. بعد ذلك ، ستكون قادرًا على إنشاء أي مجموعة من الأشكال لتمثيل أنواع التعيين التي تريدها ، وتوفير عمليات التنفيذ بحيث تتوافق المجموعات الحالية مثل HashSet<T> معها.

يمكن بعد ذلك أن تظهر مكتبة مجتمعية للقيام بذلك بالضبط ، تغطي جميع الأنواع المختلفة من المجموعات (المكثفة (المسندات) والتوسعية (المدرجة) ، مرتبة ، مرتبة جزئيًا ، غير مرتبة ، قابلة للعد ، لانهائية إلى حد ما ، لا حصر لها ، ربما المجالات الرياضية أيضًا مثل عقلاني ، والأرقام الطبيعية ، إلخ) كأشكال مختلفة ، مع كل طرق الاتحاد والتقاطع والأصل المحددة لهذه المجموعات وفيما بينها.

هذا يبدو لي وكأنه 5 سنوات على الطريق. لماذا يجب أن ينتظر التغيير البسيط الذي يمكن تنفيذه في يوم واحد ميزة غير محددة حتى الآن أكبر 1000 مرة والتي قد لا تحدث حتى؟

هذا يبدو لي وكأنه 5 سنوات على الطريق. لماذا يجب أن ينتظر التغيير البسيط الذي يمكن تنفيذه في يوم واحد ميزة غير محددة حتى الآن أكبر 1000 مرة والتي قد لا تحدث حتى؟

أنا أستجيب فقط لنقص التقدم في 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> {
     }
 }

افعلها! أتحداكم!

تضمين التغريدة

لا يمكننا أن نجعل ISet<T> يمتد IReadOnlySet<T> (لنفس السبب الذي لا يمكننا فعله مع الواجهات الأخرى القابلة للتغيير).

هل لا يزال هذا صحيحًا حتى مع طرق الواجهة الافتراضية؟ هل هذا يعني أنه يجب إغلاق https://github.com/dotnet/corefx/issues/41409 ؟

تضمين التغريدة

لا يمكننا أن نجعل ISet<T> يمتد IReadOnlySet<T> (لنفس السبب الذي لا يمكننا فعله مع الواجهات الأخرى القابلة للتغيير).

هل لا يزال هذا صحيحًا حتى مع طرق الواجهة الافتراضية؟ هل هذا يعني أنه يجب إغلاق dotnet / corefx # 41409 ؟

ناقشنا هذا. اعتدنا على الاعتقاد بأن DIMs ستعمل ، ولكن عندما نسير في الحل ، خلصنا إلى أنه سيؤدي بشكل شائع إلى ماسة شظية مما يؤدي إلى تطابق غامض. ومع ذلك ، فقد تم تحدي هذا مؤخرًا ، لذا أعتقد أنه يجب علي كتابته والتأكد من أنه يعمل بالفعل أو لا يعمل.

terrajobst / danmosemsft هل تم تعيين أي شخص لهذا؟

و terrajobst لتوضيح العمل الذي نريد تحقيقه هو:
""
يجب علينا أيضًا تنفيذ IReadOnlySetعلى مجموعة غير قابلة للتغييرو ImmutableHashSet(وبناؤهم)
يجب علينا البحث عن تطبيقات أخرى لـ ISet.
""
بالإضافة إلى تنفيذ الواجهات أعلاه على HashSet و SortedSet.

يجري المسح فقط بالبحث عن أي شيء وإحضاره إذا كان يبدو مشكوكًا فيه.

إذا كان هذا لا يزال متاحًا ، فسأكون مهتمًا

Jlalond كلا ، مخصصة لك. شكرا على العرض.

تضمين التغريدة
مجرد تحديث. أنا أعمل على هذا ، أضفت الواجهة إلى النواة الخاصة Lib ، فقط تعثرت في طريقي من خلال الحصول على مجموعات.

السؤال الأخير إذا كنت تعرف رأسك دان ، فهل أحتاج إلى إجراء أي تغييرات على Mono من أجل هذا؟ لست خبيرًا في تحديد المكان الذي ينتهي فيه corefx ويبدأ mono. لذلك إذا كنت تعلم أنه يمكن أن ينقذني من بعض الأبحاث المستقلة

Jlalond لا تحتاج إلى إجراء تغييرات على Mono. جزء من سبب نقل وقت تشغيل Mono إلى هذا الريبو هو جعله سلسًا لاستخدام نفس المكتبات بالضبط مع CoreCLR أو Mono runtime. لا يوجد سوى جزء صغير من المكتبة الأساسية يتباعد:
coreclrsrcSystem.Private.CoreLib مقابل mononetcoreSystem.Private.CoreLib. (تتم مشاركة معظم المكتبة الأساسية خارج LibrariesSystem.Private.CoreLib). لذلك ما لم تلمس ذلك - فأنت لا تتأثر.

danmosemsft شكرًا على التوضيح ، وآمل أن يتم ذلك قريبًا.

مرحبًا danmosemsft فقط تابع هذا. يتم إنشاء CoreLib في تجميعات src التي يمكنني رؤية التغييرات المشار إليها. ومع ذلك ، يبدو أن تجميعات المرجع لا تكتشف أي تغييرات. هذا كل ما يعيقني ، لكن لا يمكنني العثور على أي معلومات في المستندات. أي أشخاص أو مؤشرات يمكنك إعطائي إياها حتى أتمكن من إنجاز ذلك (أعني ، بعد 5 سنوات)

العنوان # 32488