Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There's no existing extension method like what you have. Let me explain why I think that is (aside from the obvious "because it wasn't specified, implemented, tested, documented, etc." reason).</p> <p>Basically, this implementation is necessarily inefficient. Constructing an array from the parameters passed to <code>In</code> (as happens when you use the <code>params</code> keyword) is an O(N) operation and causes gratuitous GC pressure (from the construction of a new <code>T[]</code> object). <code>Contains</code> then enumerates over that array, which means your original code has been more than doubled in execution time (instead of one partial enumeration via short-circuited evaluation, you've got one full enumeration followed by a partial enumeration).</p> <p>The GC pressure caused by the array construction <em>could</em> be alleviated somewhat by replacing the <code>params</code> version of the extension method with X overloads taking from 1 to X parameters of type <code>T</code> where X is some reasonable number... like 1-2 dozen. But this does not change the fact that you're passing X values onto a new level of the call stack only to check potentially less than X of them (i.e., it does not eliminate the performance penalty, only reduces it).</p> <p>And then there's another issue: if you intend for this <code>In</code> extension method to serve as a replacement for a bunch of chained <code>||</code> comparisons, there's something else you might be overlooking. With <code>||</code>, you get short-circuited evaluation; the same doesn't hold for parameters passed to methods. In the case of an enum, like in your example, this doesn't matter. But consider this code:</p> <pre><code>if (0 == array.Length || 0 == array[0].Length || 0 == array[0][0].Length) { // One of the arrays is empty. } </code></pre> <p>The above (weird/bad -- for illustration only) code should not throw an <code>IndexOutOfRangeException</code> (it could throw a <code>NullReferenceException</code>, but that's irrelevant to the point I'm making). However, the "equivalent" code using <code>In</code> very well could:</p> <pre><code>if (0.In(array.Length, array[0].Length, array[0][0].Length) { // This code will only be reached if array[0][0].Length == 0; // otherwise an exception will be thrown. } </code></pre> <p>I'm not saying your <code>In</code> extension idea is a bad one. In most cases, where used properly, it can save on typing and the performance/memory cost will not be noticeable. I'm just offering my thoughts on why a method of this sort would not be appropriate as a built-in library method: because its costs and limitations would likely be misunderstood, leading to over-use and suboptimal code.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload