Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I went through a phase of passing around <code>T[]</code>, and to cut a long story short, it's a pain in the backside. <code>IEnumerable&lt;T&gt;</code> is much better</p> <blockquote> <p><em>However I wonder, with the late evaluation of the IEnumerable generic type if that is a good idea. Does it make more sense to use the T[] generic type? IList? Or something else</em></p> </blockquote> <p>Late evaluation is precisely why <code>IEnumerable</code> is so good. Here's an example workflow:</p> <pre><code>IEnumerable&lt;string&gt; files = FindFileNames(); IEnumerable&lt;string&gt; matched = files.Where( f =&gt; f.EndsWith(".txt") ); IEnumerable&lt;string&gt; contents = matched.Select( f =&gt; File.ReadAllText(f) ); bool foundContents = contents.Any( s =&gt; s.Contains("orion") ); </code></pre> <p>For the impatient, this gets a list of filenames, filters out <code>.txt</code> files, then sets the <code>foundContents</code> to true if any of the text files contain the word <code>orion</code>.</p> <p>If you write the code using <code>IEnumerable</code> as above, you will only load each file one by one as you need them. Your memory usage will be quite low, and if you match on the first file, you prevent the need to look at any subsequent files. It's great.</p> <p>If you wrote this exact same code using arrays, you'd end up loading all the file contents up front, and only then (if you have any RAM left) would any of them be scanned. Hopefully this gets the point across about why lazy lists are so good.</p> <blockquote> <p><em>One thing that has not gotten addressed though seems to be the issue of thread safety. If, for example, you take an <code>IEnumerable&lt;T&gt;</code> argument to a method and it gets enumerated in a different thread, then when that thread attempts to access it the results might be different than those that were meant to be passed in. Worse still, attempting to enumerate an <code>IEnumerable&lt;T&gt;</code> twice - I believe throws an exception. Shouldn't we be striving to make our methods thread safe?</em></p> </blockquote> <p>Thread safety is a giant red herring here.</p> <p>If you used an array rather than an enumerable, it <em>looks</em> like it should be safer, but it's not. Most of the time when people return arrays of objects, they create a new array, and then put the old objects in it. If you return that array, then those original objects can then be modified, and you end up with precisely the kind of threading problems you're trying to avoid.</p> <p>A <em>partial</em> solution is to not return an array of the original objects, but an array of new or cloned objects, so other threads can't access the original ones. This is useful, however there's no reason an <code>IEnumerable</code> solution can't also do this. One is no more threadsafe than the other.</p>
    singulars
    1. This table or related slice is empty.
    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