Nunit: अनुरोध: PropertyConstraint में अनुक्रमणिका का समर्थन जोड़ें

मुझे यह विचार पसंद आया।

सी # नामित अनुक्रमित गुणों का समर्थन नहीं करता है लेकिन वीबीएनईटी करता है। मुझे लगता है कि सिंटैक्स .Property("Name", index1, ...) नामित इंडेक्सर्स के लिए आरक्षित होना चाहिए, इसलिए मैं इसे डिफ़ॉल्ट इंडेक्सर के लिए उपयोग नहीं करना चाहता हूं। मैं लोगों को नाम पैरामीटर में पास करने की आवश्यकता नहीं करके सी # भाषा का सम्मान करने में सक्षम होना चाहता हूं।

आप Has.Item("TEST1").EqualTo("1") या Has.Index("TEST1").EqualTo("1") बारे में क्या सोचते हैं?

@jnm2
शॉर्टकट के रूप में "आइटम" या "इंडेक्सर" विधि का होना सुविधाजनक है, लेकिन सी # में इंडेक्सर का नाम बदलना वास्तव में संभव है: https://stackoverflow.com/questions/5110403/class-with-indexer-and-property-named -आइटम

@ Ch0senOne नाम बदलना संभव है। स्पष्ट होने के लिए मुझे कहना चाहिए था, सी # में एक गैर-डिफ़ॉल्ट अनुक्रमणिका बनाना संभव नहीं है। उदाहरण के लिए, आप दो इंडेक्सर्स घोषित नहीं कर सकते हैं, न ही आप सी # से नाम का उपभोग कर सकते हैं।
इसके बारे में सोचकर मुझे डर है कि Has.Item("value") Contains.Item साथ बहुत भ्रमित होगा। तो शायद Has.Index("value") ?

इसलिए मैं के पक्ष में हो जाएगा Has.Index("IndexValue") डिफ़ॉल्ट इंडेक्सर के लिए और Has.Property("PropertyName", indexParams) गैर-डिफ़ॉल्ट indexers के लिए। Has.Property डिफ़ॉल्ट इंडेक्सर्स के लिए भी काम करना समाप्त कर देगा, भले ही मुहावरेदार सी # बात करने के लिए Has.Index का उपयोग करना होगा।

या अगर हम प्यारा बनना चाहते हैं, तो हम Has.Index["IndexValue"] और
Has.Property("PropertyName")[indexparams] ...

वास्तव में, मुझे आश्चर्य है कि अगर हम साथ भाग मिल सकता है Has.Item["AtIndex"] क्रम में इंडेक्सर सिंटेक्स के उपयोग के साथ भ्रमित किया जा रहा से बचने के लिए Contains.Item("ItemValue") ... यकीन नहीं है कि मैं क्या है कि बारे में सोचते हैं!

आइए देखें कि अन्य @ नूनिट/फ्रेमवर्क-टीम के सदस्य क्या सोचते हैं।

हमने पहले से ही स्ट्रिंग्स के बजाय लैम्ब्डा का उपयोग करके गुणों पर जाने के लिए एक दिशा परिभाषित की है। ऐसा लगता है कि उस पर बेहतर समय बिताया जा सकता है। मैं अपने फोन पर हूं इसलिए मैं आपको इश्यू नंबर नहीं दे सकता।

@CharliePoole https://github.com/nunit/nunit/issues/26?

यह Has.Property लिए समझ में आता है। हम कर सकते थे:

• Has.Property(_ => _.PropertyName[index1, ...])
• Has.Property(_ => _.PropertyName, index1, ...)

मुझे अब भी लगता है कि हमें Has.Property तब तक कुछ नहीं करना चाहिए जब तक कि गैर-डिफ़ॉल्ट गुणों की आवश्यकता न हो, और अभी के लिए केवल Has.Index(value1, ...) या Has.Index[value1, ...] या Has.Item[value1, ...] प्रदान करें बहुत अधिक सामान्य डिफ़ॉल्ट अनुक्रमणिका।

वही है वो। मैं आपके साथ नामित अनुक्रमणकों पर सहमत हूं, जिनका वैसे भी अनुरोध नहीं किया गया है।

@ jnm2 आपके विचार के लिए, आप एक बहु-कुंजी अनुक्रमणिका भी बना सकते हैं। उदाहरण के लिए

this[string key1, string key2]

मैं सोच रहा हूं कि इस मुद्दे पर कोई अपडेट है, या ऐसे प्रकार पर इंडेक्सर्स का परीक्षण करने का वर्तमान तरीका है जो IEnumerable का उत्तराधिकारी नहीं है। मुझे लगता है कि मैं सिर्फ एक KeyNotFoundException को फेंकने की जांच कर सकता हूं। इंडेक्सर में एक कुंजी के अस्तित्व की जांच करने की अनुमति देने के लिए मैं और कुछ भी देख रहा हूं?

@ क्रश83 हां, मेरा index1, ... सिंटैक्स यह इंगित करने के लिए था कि हम जो कुछ भी करते हैं उस पर हमें विचार करना चाहिए।

मुझे शब्दावली कुंजी पसंद नहीं है जब तक कि हम किसी ऐसी वस्तु के बारे में बात नहीं कर रहे हैं जो वास्तव में एक शब्दकोश या कुंजी संग्रह है। वे डिफ़ॉल्ट इंडेक्सर्स वाली चीजें हैं, लेकिन डिफॉल्ट इंडेक्सर्स वाली सभी चीजों में चाबियां नहीं होती हैं। (चूंकि आप इस शब्दावली का उपयोग कर रहे हैं, हो सकता है कि आपको हमारा Contains.Key सिंटैक्स मददगार लगे? क्या हम इसे सुधार सकते हैं?)

आप यहां जो देख रहे हैं, उसके अलावा कोई प्रगति नहीं हुई है। हमें एक प्रस्ताव चाहिए। वहां कुछ डालने के लिए, मेरा वर्तमान पसंदीदा Has.Item(params object[] indexerArgs) जो डिफ़ॉल्ट इंडेक्सर को कॉल करेगा चाहे उसका नाम कुछ भी हो।
क्या यह सब कुछ अब तक अनुरोध किया जाएगा?

+1

@ nunit/ढांचा-टीम क्या आप निम्न नए API का समर्थन करेंगे?

namespace NUnit.Framework
{
    public abstract class Has
    {
        public static ResolvableConstraintExpression Property(string name);

+       public static ResolvableConstraintExpression Item(params object[] indexerArgs);
    }
}

namespace NUnit.Framework.Constraints
{
    public class ConstraintExpression
    {
        public ResolvableConstraintExpression Property(string name);

+       public ResolvableConstraintExpression Item(params object[] indexerArgs);
    }
}

मैं शायद IndexerConstraint कक्षा को तब तक आंतरिक छोड़ दूंगा जब तक कि इसे एपीआई में जोड़ने का कोई कारण न हो।

मुझे अच्छा लगता है।

पक्ष में एक और वोट, मैं सिर्फ इस सुविधा को कंसोल टेस्ट के लिए चाहता था। 🙂

@jnm2 क्या यह समस्या अभी भी कुछ ऐसा है जो टीम करना चाहती है?

मेरे पास इस मुद्दे के माध्यम से एक त्वरित squiz था और जैसा कि मुझे समझ में नहीं आता कि समर्थित एपीआई जैसा दिखना चाहिए - क्या यह है:

/// obj from the initial post example
Assert.That(obj, Has.Item("TEST1").EqualTo(1).And.Item("TEST2").EqualTo(2));

या यह है:

Assert.That(obj, Has.Item("TEST1", 1).And.Item("TEST2", 2));

?

आप उदाहरण params object[] लेते हैं

ऑप्ट मानते हुए। 2, क्या सरणी की आवश्यकता होगी जैसे कि केवल एक वस्तु प्रदान की गई हो, दावा करें कि कुंजी मौजूद है, 2 पैरामीटर - कुंजी और मान? अन्य संयोजन (अधिक या कम अपेक्षित पैरामीटर), विफल?

@Poimen हाँ, और हम मदद की सराहना करेंगे!

सरणी आवश्यक है क्योंकि अनुक्रमणिका एक से अधिक तर्क ले सकती है। उदाहरण के लिए:

public string this[int x] => "First indexer";

public string this[string x] => "Second indexer";

public string this[int x, int y] => "Third indexer";

आप Has.Item(42).EqualTo("First indexer") , Has.Item("42").EqualTo("Second indexer") , और Has.Item(1, 2).EqualTo("Third indexer") ।

देखिए, आप हर दिन कुछ नया सीखते हैं - मैंने मान लिया था कि यह एक टाइपो था, उफ़: देखें_नो_एविल: मुझे पहले मल्टी-की इंडेक्सर का उपयोग करने का आनंद नहीं मिला है ...

ठीक है, बढ़िया, मैं इस सप्ताह कुछ एक साथ रखने पर विचार करूँगी।

@ jnm2 मैंने इस मुद्दे के लिए एक पीआर बनाया है।

मेरे पास जो एक चिंता है वह त्रुटि संदेश है जो कोड द्वारा निर्मित होता है:

Has.Item(42)

त्रुटि संदेश थोड़ा "हैकी" है, लेकिन मुझे यकीन नहीं है कि इसे हल करने का सबसे साफ तरीका क्या है। "हैक" है:
https://github.com/nunit/nunit/pull/3609/commits/96154ca6402c692cec5e0ae6947f9922e72799fe#diff -ceeee4b8399633f181b6bccd5a39eb32R72

@Poimen क्षमा करें, सुनिश्चित नहीं है कि आपका क्या मतलब है। वर्तमान में क्या संदेश है, और आप इसे क्या बनाना चाहेंगे? या आप सुझाव ढूंढ रहे हैं?

@ jnm2 प्रकट

  Expected: indexer [System.Int32]
  But was:  "not found"

जिस तरह से त्रुटि संदेश बनते हैं StringifyArguments फ़ंक्शन थोड़ा "हैकी" है।

तो मेरा बुरी तरह से व्यक्त प्रश्न अधिक है यदि वांछित संदेश आउटपुट बनाने का एक क्लीनर तरीका था।

@ jnm2 मुझे लगता है कि मैंने समीक्षा पर टिप्पणियों को संबोधित किया है (उनके लिए धन्यवाद)। लेबल कहता है awaiting:contributor ।

मुझे यकीन नहीं है कि कुछ और है जो मुझे आपको यह बताने के लिए करने की ज़रूरत है कि मैं "हो गया": +1:

मुझे लगता है कि जब Has.Property को कोई प्रॉपर्टी नहीं मिल रही है, तो हमें उस संदेश के जितना संभव हो उतना करीब बनाना चाहिए। फिर हमें property को default indexer से बदलना चाहिए और संपत्ति के नाम को accepting arguments [42] या ऐसा कुछ से बदलना चाहिए। मैं यह सोचने की ओर झुकता हूं कि हमें तर्क प्रकारों को सूचीबद्ध करने के बजाय तर्क मान दिखाने के लिए MsgUtils.FormatCollection जैसे मौजूदा स्वरूपण सहायकों में से एक का उपयोग करना चाहिए। उदाहरण के लिए, तर्कों में से एक शून्य हो सकता है और कई प्रकार के साथ काम कर सकता है।

नहीं, यह बहुत अच्छा है! पीआर थ्रेड में ठीक उसी तरह की एक टिप्पणी आदर्श होगी।

दावे को देखते हुए:
```सी#
Assert.that (परीक्षक, Has.Item ("वाह"));

It producers the message:

अपेक्षित: डिफॉल्ट इंडेक्सर तर्कों को स्वीकार करता है <>
लेकिन था: "नहीं मिला"

Given the assertion:
```c#
Assert.That(tester, Has.Item("wow").EqualTo(1));

यह संदेशों को प्रोड्यूस करता है:

Default indexer accepting arguments < "wow" > was not found on NUnit.Framework.Constraints.IndexerConstraintTests+NamedIndexTester.

यह MsgUtils.FormatCollection फ़ंक्शन का उपयोग करके उत्पन्न हुआ।

तो अतिरिक्त विवरण के साथ संपत्ति संदेशों से भी अधिक निकटता से मेल खाता है।

मुझे दूसरा मामला बहुत पसंद है। पहला मामला अभी भी मेरे लिए अर्थपूर्ण रूप से गलत लगता है क्योंकि यह तर्क मानों के बजाय तर्क प्रकार दिखाता है। हमारे पास केवल तर्क मान हैं, और प्रत्येक तर्क मान अनुक्रमणिका में तर्क प्रकारों की श्रेणी से मेल खा सकता है। यह दिखाना भ्रामक है कि System.String तर्क के साथ एक अनुक्रमणिका होना चाहिए क्योंकि IEnumerable<char> तर्क ठीक वैसे ही काम करेगा।

IEnumerable<char> एक निराला उपयोग का मामला है ... लेकिन निश्चित रूप से, मुझे यह बात समझ में आ गई है।

तो, वापस - दिया गया:
```सी#
Assert.that (परीक्षक, Has.Item ("वाह"));

producers the message:

अपेक्षित: डिफॉल्ट इंडेक्सर तर्कों को स्वीकार करता है < "वाह" >
लेकिन था: "नहीं मिला"

For numbers it goes into the usual suffix - given:
```c#
Assert.That(tester, Has.Item(42d));

निर्माता:

  Expected: Default indexer accepting arguments < 42.0d >
  But was:  "not found"

'अपेक्षित' संदेश मुझे तब बहुत अच्छा लगता है। But was: "not found" संदेश थोड़ा ऐसा लगता है जैसे यह सामग्री के साथ एक स्ट्रिंग इंस्टेंस के बारे में बात कर रहा है not found , लेकिन अगर PropertyConstraint उसी तरह व्यवहार करता है, तो उन्हें वही रखना मेरे लिए बेहतर है। प्रॉपर्टी कॉन्स्ट्रेन बदलना डिफ़ॉल्ट रूप से इस पीआर के दायरे से बाहर होगा। यदि आप चाहें तो हम अभी भी बदलाव कर सकते हैं और मैंने और फ्रेमवर्क टीम में किसी और ने बदलाव को ठीक किया है।

हाँ, मैं इसे ऐसा नहीं करने की कोशिश कर रहा था, लेकिन मुझे त्रुटि संदेश के साथ कोई समाधान नहीं मिला। मुझे यह पसंद आया होगा:

But was: not found

लेकिन ConstraintResult की वापसी वहां स्ट्रिंग कोट्स डाल रही है।

संदर्भ के लिए संपत्ति संस्करण:
```सी#
Assert.that (परीक्षक, Has.Property ("NoItDoesNotHaveThis"));

produces:

अपेक्षित: संपत्ति NoItDoesNotHaveThis
मगर था:
```
तो कोई उद्धरण नहीं है - लेकिन यह प्रकार देता है - मान नहीं।

मुझे यकीन नहीं था कि ConstraintResult का अधिभार लौटाना एक समाधान होगा?

मुझे लगता है कि निरंतरता के लिए PropertyConstraint क्या कर रहा है, इसके साथ हमें रहना चाहिए। actual मान क्या है इसका डिफ़ॉल्ट प्रतिनिधित्व दिखाना सबसे बुरी बात नहीं है जब संदेश कह रहा है कि जो विफल रहा वह संपत्ति ढूंढ रहा था।

ConstraintResult से व्युत्पन्न एक नया वर्ग लौटाना यह है कि अन्य बाधाएं इसे कैसे अनुकूलित करती हैं, हां।

ठीक है, बढ़िया - लगता है - दिया गया:
```सी#
जोर दें। वह (परीक्षक, है। आइटम (42 डी));

producers:

अपेक्षित: तर्कों को स्वीकार करने वाला डिफ़ॉल्ट अनुक्रमणिका < 42.0d >
मगर था:
```

यह संपत्ति बाधा संदेश से मेल खाता है।

@ nunit/ढांचे-टीम और सभी, मैं इस प्रश्न पर शीघ्र समाधान की उम्मीद कर रहा हूं क्योंकि @Poimen का उत्कृष्ट पीआर (https://github.com/nunit/nunit/pull/3609) अन्यथा विलय के लिए तैयार है।

@Dreamescaper ने मेरे ध्यान में मेरी चिंता को इस धागे में ऊपर लाया कि मैंने ट्रैक खो दिया: मुझे डर है कि लोग Assert.That(collection, Has.Item("x")); लिखेंगे और पढ़ेंगे यह सोचकर कि Has.Item अर्थ Contains.Item .
हम विफलता संदेश में कुछ जोड़ने पर विचार कर सकते हैं, लेकिन इससे स्रोत कोड में Has.Item पढ़ते समय इसे ठीक से समझने की समस्या में मदद नहीं मिलेगी:

  Expected: Default indexer accepting arguments < 42.0d > (Did you mean to use Contains.Item?)

दूसरी ओर, मुझे Has.Index(42) या Has.Index(42).EqualTo(43) है जो मैंने Item बजाय सुझाया था। उदाहरण के एक सूचकांक में एक आइटम है। आप यह नहीं कहेंगे कि इंस्टेंस में एक इंडेक्स है और यह इंडेक्स 43 के बराबर है। इंडेक्स वह चीज है जिसे आप पास करते हैं, 42।

कुछ विकल्प

• Has.Item उपयोग करें। स्रोत कोड पढ़ते समय होने वाली समस्याओं को छोड़ दें। हो सकता है कि स्रोत कोड लिखते समय मदद करने के लिए कुछ न्यूनीकरण जोड़ें, जैसे XML दस्तावेज़ और विफलता संदेशों में युक्तियाँ।
• शब्दावली के अजीब मिश्रण के बावजूद Has.Index का प्रयोग करें।
• इसके बजाय Has.ItemAt उपयोग करें। Has.ItemAt(42).EqualTo(43) ।

रुको, मुझे आखिरी सुझाव से प्यार हो गया क्योंकि इसमें LINQ ElementAt विधि के समानांतर है जिसे एक इंडेक्स दिया जाता है और एक आइटम देता है।

क्या हर कोई Has.ItemAt खुश है? सुझावों का स्वागत है लेकिन फिर से मैं उस समय का सम्मान करना चाहता हूं जो @Poimen ने पहले ही समर्पित कर दिया है।

Has.ItemAt लिए +1 :)

मैं आपसे सहमत हूं कि Has.Item संभावित रूप से भ्रमित करने वाला है। मुझे Has.ItemAt पसंद है लेकिन चूंकि आपको LINQ सिंटैक्स पसंद है, इसलिए Has.ElementAt उपयोग क्यों न करें?

मैं ElementAt के बारे में निश्चित नहीं हूं, क्योंकि यह प्रत्यक्ष समकक्ष नहीं है।
उदाहरण के लिए Dictionary<string,string> LINQ का ElementAt(0) पहली जोड़ी लौटाएगा, और Has.ItemTo(0).EqualTo("...") विफल हो जाएगा, क्योंकि पूर्णांक स्वीकार करने वाला कोई अनुक्रमणिका नहीं है।

@CharliePoole यह वास्तव में एक अच्छा विचार है। ऐसा लगता है कि इसे खोजना उतना सहज नहीं होगा, लेकिन मुझे नहीं पता कि मुझे ऐसा क्यों लगता है। मुझे लगता है कि मैं Item पसंद करता हूं क्योंकि हम किसी प्रकार के संग्रह/शब्दकोश/लुकअप पर एक इंडेक्सर को कॉल करेंगे, जबकि ElementAt का उद्देश्य प्रश्नों और अन्य गणनाओं में काम करना है जो आवश्यक रूप से संग्रह नहीं हैं . संग्रह तत्वों को आमतौर पर आइटम कहा जाता है।

@Dreamescaper क्या आपको लगता है कि Has.ItemAt(4) लोगों को यह सोचने पर मजबूर कर सकता है कि यह ElementAt तरह काम करता है, एक इंडेक्सर को कॉल करने के बजाय गणना?

@jnm2
यह शायद हो सकता है, लेकिन मुझे एक बेहतर विकल्प नहीं पता (और मुझे लगता है कि यह अभी भी Has.Item से बेहतर विकल्प है)।

@ jnm2 मैं वास्तव में थोड़ा भ्रमित हूँ। यह मुद्दा गुणों के बारे में शुरू हुआ और अभी भी इसका शीर्षक है। Has.Property और Has.ItemAt उपयोगकर्ता की नज़र में एक दूसरे से कैसे संबंधित या बातचीत या तुलना करेंगे?

[मुझे एहसास है कि गुणों और संग्रह वस्तुओं को अमूर्तता के एक निश्चित स्तर पर समकक्ष माना जा सकता है, लेकिन मुझे नहीं लगता कि यह अमूर्तता का स्तर है जिस पर हम में से अधिकांश आमतौर पर काम करते हैं। :स्माइलिंग_इम्प: ]

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

मैं आंशिक रूप से ItemAt से अधिक ElementAt साथ सबसे अधिक सहज महसूस करता हूं क्योंकि ऐसा लग सकता है कि हम Enumerable.ElementAt के समान विशेष दृष्टिकोण को सौंपते हैं या लेते हैं। जिस चीज ने मुझे ElementAt(int index) साथ दृढ़ता से प्रभावित किया वह यह था कि यह कैसे काम करता है और अधिक तथ्य यह है कि बीसीएल में At प्रत्यय के लिए उदाहरण है, विशेष रूप से index नामक पैरामीटर से जुड़ा हुआ है

यदि आप इसे ILookup के साथ उपयोग करते हैं, तो ILookup की प्रत्येक अनुक्रमणिका एकाधिक TElements लौटाती है, एक भी तत्व/वस्तु नहीं। Has.EntryAt कुछ ऐसा हो सकता है जो संग्रह, शब्दकोश और बहु-तत्व-प्रति-सूचकांक लुकअप के साथ काम करता है। मेरी प्रारंभिक प्रतिक्रिया यह है कि Has.ItemAt जो एक ILookup से IEnumerable<TElement> लौटाता है, शायद काफी समझ में आता

आप सब क्या सोचते हैं? यह कठिन है जब आप एक से अधिक चीजों को काम करते हुए देख सकते हैं, लेकिन यहां बहुमत वरीयता यह इंगित करने में भी मदद कर सकती है कि लोगों के लिए कौन सा नाम सबसे आसान होगा। @ नूनिट/फ्रेमवर्क-टीम के अलावा लोग, मेरा मतलब आपको बाहर करना नहीं था। यदि आप देख रहे हैं और आपके पास एक मजबूत भावना है, तो यह एक डेटा बिंदु है जो हमेशा सहायक होता है!

@CharliePoole Has.Property("X") दावा है कि उदाहरण में X नामक एक गैर-पैरामीटरयुक्त संपत्ति है। Has.ItemAt("X") यह दावा करेगा कि इंस्टेंस में एक डिफ़ॉल्ट इंडेक्सर (एक अप्रासंगिक, प्रसिद्ध नाम वाला एक पैरामीटरयुक्त गुण) है जो एक स्ट्रिंग पैरामीटर को स्वीकार कर सकता है।

Has.Property("X").EqualTo(3) का दावा है कि उदाहरण के एक गैर पैरामिट्रीकृत संपत्ति कहा जाता है X कि रिटर्न 3 अगर तुम फोन अपने गैर पैरामिट्रीकृत get एक्सेसर। Has.ItemAt("X").EqualTo(3) यह दावा करेगा कि इंस्टेंस में एक डिफ़ॉल्ट इंडेक्सर (एक अप्रासंगिक, प्रसिद्ध नाम के साथ एक पैरामीटरयुक्त संपत्ति) है जो 3 लौटाता है यदि आप विशिष्ट स्ट्रिंग "X" को पास करते हैं get एक्सेसर।

डिफ़ॉल्ट इंडेक्सर का नाम अप्रासंगिक है कि सी #, वीबी और एफ # सिंटैक्स सभी नाम निर्दिष्ट किए बिना डिफ़ॉल्ट इंडेक्सर्स को कॉल कर सकते हैं। (इस प्रकार 'डिफॉल्ट' शब्द) एक ऐसी भाषा जिसमें डिफॉल्ट इंडेक्सर्स की कोई अवधारणा नहीं थी, लेकिन नामित इंडेक्सर्स की अवधारणा थी, उसे नाम निर्दिष्ट करना होगा। डिफ़ॉल्ट इंडेक्सर का नाम आमतौर पर Item , लेकिन डिफ़ॉल्ट इंडेक्सर को कुछ मनमाना नाम दिया जा सकता है और फिर भी डिफ़ॉल्ट इंडेक्सर हो सकता है क्योंकि वे भाषाएं अभी भी नाम निर्दिष्ट किए बिना इसे कॉल करने में सक्षम होंगी। C# में, आप इसे [IndexerName("ArbitraryName")] विशेषता का उपयोग करके पूरा करेंगे।

@ jnm2 मैं वास्तव में

मुझे लगता है कि संपत्ति के बीच भ्रम की संभावना है

• __बीइंग__ वास्तविक वस्तु का सूचकांक
• __रिटर्निंग__ एक वस्तु जिसमें एक अनुक्रमणिका है
• __रिटर्निंग__ एक संग्रह जिसमें आइटम हैं

मैं इस बात पर जोर देता हूं कि __you__ भ्रमित नहीं होगा और मैं शायद केवल आपके साथ बात करते समय होने का दिखावा करूंगा (ईश्वरीय विधि, y' पता है: पलक:) लेकिन मुझे संदेह है कि कई इसे भ्रमित कर सकते हैं और आप इसे लोगों को समझाएंगे। काफी।

मैं जोड़ के खिलाफ नहीं हूं, लेकिन मुझे लगता है कि उपरोक्त भेदों को दस्तावेज़ों में लिखा जाना चाहिए।

पुनश्च: मुझे बिल्कुल भी बहिष्कृत महसूस नहीं हुआ। :स्माइली:

@CharliePoole अच्छा विचार। क्या हम उस विचार को तब तक सूचीबद्ध कर सकते हैं जब तक हम किसी नाम पर समझौता नहीं कर लेते, क्योंकि ऐसा लगता है कि यह Has.ItemAt / Has.ElementAt / Has.EntryAt /etc के बीच के चुनाव को प्रभावित नहीं करेगा? या क्या कोई ऐसा बिंदु है जिससे मैं चूक गया और आप भ्रम की इस क्षमता के आधार पर एक विशेष नामकरण विकल्प का समर्थन कर रहे हैं?

अब तक मैं ItemAt की ओर झुक रहा हूं। @Dreamescaper , क्या आप अभी भी वहीं हैं? @CharliePoole मुझे यकीन नहीं था कि आप ElementAt लिए वरीयता व्यक्त कर रहे थे या प्रक्रिया के माध्यम से सोचने में हमारी सहायता कर रहे थे।

जितने अधिक लोग Has.ItemAt / Has.ElementAt / Has.EntryAt /other पर झंकार करते हैं, उतना ही अधिक आत्मविश्वास हम लोगों को सहज ज्ञान युक्त पाएंगे। मैं इसे केवल उसी के लिए कॉल करना चाहता हूं जो अगले दिन या उसके बाद लीड में प्रतीत होता है, क्योंकि यदि हम इससे अधिक समय लेते हैं तो हम इतनी छोटी राशि से 3.13 रिलीज़ को याद करेंगे।

@jnm2 बस इसे अपने आप से सोचने और इसे प्रोत्साहित करने की कोशिश कर रहा हूं।

शब्दों का चयन WRT, मैं सोच रहा था कि क्या कुछ विशेष शब्द मेरे द्वारा सूचीबद्ध तीन प्रकार के भावों के साथ सबसे अच्छा काम करेंगे और यह भी कि क्या चिंता करने के लिए कोई अन्य संयोजन है। मैंने जिन तीन विकल्पों का उल्लेख किया है, उनके साथ आपके पास होगा

• Has.ItemAt("foo").EqualTo("bar")
• `Has.Property("Bing").with.ItemAt("foo").EqualTo("bar")
• `Has.Property("Bing").with.One.EqualTo("bar")

तो मुझे लगता है कि आप सही कह रहे हैं कि किसी भी विकल्प के लिए शब्दांकन कोई मायने नहीं रखता

लंबी अवधि की ओर देखते हुए, मैं वर्ग कोष्ठक के साथ वास्तविक अनुक्रमण का उपयोग करूंगा। लेकिन इसके लिए कक्षाओं के एक सेट के रूप में मॉडलिंग के बजाय वास्तव में बाधा अभिव्यक्ति को संकलित करने की आवश्यकता होगी।

मुझे पता है कि यह मेरे वेतन-ग्रेड से ऊपर है: मुस्कान:, लेकिन मुझे लगा कि मैं यहां झंकार करूंगा ...

मुझे पसंद है ItemAt ।

मैंने समय बिताया, जैसा कि @CharliePoole ने सुझाव दिया, कुछ उपयोग के मामलों के बारे में सोचकर। मुझे यह विचार आया कि ElementAt का उपयोग IEnumerable स्थितियों में अधिक किया जाता है और भाषा अनुक्रमणिका केवल IEnumerable से अधिक संभाल सकते हैं। मैं थोड़ी देर के लिए ElementAt बाड़ पर बैठा, फिर विचार किया गया:
```सी#
जोर दें। वह (..., Has.ElementAt ("एक", "दो"));

against:
```c#
Assert.That(..., Has.ItemAt("one", "two"));

उपरोक्त में ItemAt एकाधिक मूल्य सूचकांकों को व्यक्त करना अधिक स्वाभाविक लगता है।

मैंने यह भी माना कि टिकट मूल रूप से संपत्ति की कमी के लिए शॉर्ट-सर्किट के लिए था और ItemAt उस कथा के साथ फिट बैठता है। (हालांकि, यह इसे कुछ और/बेहतर/आदि में रूपांतरित करने से नहीं रोकता है, केवल एक दृष्टिकोण है)।

मुझे भी पसंद है ItemAt , तो चलिए इसे बहुमत कहते हैं और उस के पक्ष में शासन करते हैं

भ्रम को रोकने के लिए, आइए सुनिश्चित करें कि यह पूरा होने के बाद जल्दी से प्रलेखित हो जाता है और रिलीज नोट्स में शामिल हो जाता है।

@Poimen Re: आपका वेतन ग्रेड, इस बात को कम मत समझो कि हम यहाँ कैसे आगे बढ़ रहे हैं। अपने विचारों का साझा करने के लिए धन्यवाद!

और जहां तक ​​वेतन ग्रेड की बात है, चूंकि यहां हर कोई NUnit पर काम करते हुए लगभग $0 का वार्षिक वेतन प्राप्त कर रहा है, मुझे लगता है कि हम सभी समान वेतन ग्रेड पर हैं

@Dreamescaper ने पीआर में एक और अच्छा सवाल पूछा। सकारात्मक या नकारात्मक, यह पसंद करता है कि यह एक इंडेक्सर की उपस्थिति की जांच करने के बजाय गिनती की जांच करेगा:

Assert.That(new[] { 1, 2, 2 }, Has.ItemAt(3));
Assert.That(new[] { 1, 2, 2 }, Has.No.ItemAt(3));

जब तक हमारे पास इसके बारे में सोचने के लिए अधिक समय न हो, तब तक अस्तित्व की बाधा को हटाना सबसे सुरक्षित लगता है। मैं इंडेक्सर अस्तित्व जांच के लिए Has.Indexer(typeof(Type1), typeof(Type2), ...) लिए एक अलग मुद्दा खोलना पसंद करूंगा, और Has.ItemAt(arg1, arg2, ...) वास्तव में इंडेक्सर चलाने और परिणामी मूल्य के बारे में चीजों पर जोर देने के लिए।

क्या किसी को शुरू में Has.ItemAt(3) को एक बाधा का समाधान नहीं करने और Has.ItemAt(3).EqualTo(4) को हल करने के रूप में शिपिंग करने पर आपत्ति होगी?

Has.Indexer मुझे समझ में आता है। मुझे लगता है कि आप अन्य बाधाओं के साथ निरंतरता के लिए Has.Indexer<T>() , Has.Indexer<T1, T2>() आदि का भी समर्थन करेंगे।

फीडबैक देने के लिए धन्यवाद! मैंने Has.ItemAt(...) को अब स्व-समाधान करने के लिए पुल अनुरोध पर आगे बढ़ने दिया, और मैंने Has.Indexer को ट्रैक करने के लिए https://github.com/nunit/nunit/issues/3690 दायर किया। Has.Indexer उस क्षमता को प्रदान करने के लिए।