AddRange to a Collection











up vote
83
down vote

favorite
5












A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)



Sure, a foreach with Property. Add will work. But a List<T>-style AddRange would be far more elegant.



It's easy enough to write an extension method:



public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}


But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq or morelinq.



Bad design? Just Call Add? Missing the obvious?










share|improve this question




















  • 3




    Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
    – Levi
    Sep 25 '09 at 0:46










  • One problem, ICollection<T> does not seem to have an Add method. msdn.microsoft.com/en-us/library/… However Collection<T> has one.
    – Tim Goodman
    Jul 11 '13 at 5:58










  • @TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
    – TrueWill
    Jul 11 '13 at 17:26















up vote
83
down vote

favorite
5












A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)



Sure, a foreach with Property. Add will work. But a List<T>-style AddRange would be far more elegant.



It's easy enough to write an extension method:



public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}


But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq or morelinq.



Bad design? Just Call Add? Missing the obvious?










share|improve this question




















  • 3




    Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
    – Levi
    Sep 25 '09 at 0:46










  • One problem, ICollection<T> does not seem to have an Add method. msdn.microsoft.com/en-us/library/… However Collection<T> has one.
    – Tim Goodman
    Jul 11 '13 at 5:58










  • @TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
    – TrueWill
    Jul 11 '13 at 17:26













up vote
83
down vote

favorite
5









up vote
83
down vote

favorite
5






5





A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)



Sure, a foreach with Property. Add will work. But a List<T>-style AddRange would be far more elegant.



It's easy enough to write an extension method:



public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}


But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq or morelinq.



Bad design? Just Call Add? Missing the obvious?










share|improve this question















A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)



Sure, a foreach with Property. Add will work. But a List<T>-style AddRange would be far more elegant.



It's easy enough to write an extension method:



public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}


But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq or morelinq.



Bad design? Just Call Add? Missing the obvious?







c# collections c#-3.0 extension-methods






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 5 '16 at 18:22









Juan Castillo

3,42732535




3,42732535










asked Sep 25 '09 at 0:33









TrueWill

19.5k673120




19.5k673120








  • 3




    Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
    – Levi
    Sep 25 '09 at 0:46










  • One problem, ICollection<T> does not seem to have an Add method. msdn.microsoft.com/en-us/library/… However Collection<T> has one.
    – Tim Goodman
    Jul 11 '13 at 5:58










  • @TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
    – TrueWill
    Jul 11 '13 at 17:26














  • 3




    Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
    – Levi
    Sep 25 '09 at 0:46










  • One problem, ICollection<T> does not seem to have an Add method. msdn.microsoft.com/en-us/library/… However Collection<T> has one.
    – Tim Goodman
    Jul 11 '13 at 5:58










  • @TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
    – TrueWill
    Jul 11 '13 at 17:26








3




3




Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46




Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46












One problem, ICollection<T> does not seem to have an Add method. msdn.microsoft.com/en-us/library/… However Collection<T> has one.
– Tim Goodman
Jul 11 '13 at 5:58




One problem, ICollection<T> does not seem to have an Add method. msdn.microsoft.com/en-us/library/… However Collection<T> has one.
– Tim Goodman
Jul 11 '13 at 5:58












@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26




@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26












7 Answers
7






active

oldest

votes

















up vote
48
down vote



accepted










No, this seems perfectly reasonable. There is a List<T>.AddRange() method that basically does just this, but requires your collection to be a concrete List<T>.






share|improve this answer





















  • Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
    – TrueWill
    Sep 25 '09 at 0:52






  • 4




    Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
    – Reed Copsey
    Sep 25 '09 at 1:12


















up vote
29
down vote













Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.



public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
List<T> list = destination as List<T>;

if (list != null)
{
list.AddRange(source);
}
else
{
foreach (T item in source)
{
destination.Add(item);
}
}
}





share|improve this answer



















  • 2




    The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
    – rymdsmurf
    Oct 29 '14 at 12:04






  • 3




    arrgggh! Swap the condition branches, for the love of all that's holy!
    – nicodemus13
    Jul 15 '16 at 16:11






  • 9




    I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
    – nicodemus13
    Jul 20 '16 at 7:42






  • 9




    Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
    – rymdsmurf
    Jul 25 '16 at 9:39






  • 3




    Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
    – Jacob Foshee
    Sep 1 '17 at 21:47


















up vote
19
down vote













Since .NET4.5 if you want one-liner you can use System.Collections.Generic ForEach.



source.ForEach(o => destination.Add(o));


or even shorter as



source.ForEach(destination.Add);


Performance-wise it's same as for each loop (syntactic sugar).



Also don't try assigning it like



var x = source.ForEach(destination.Add) 


cause ForEach is void.






share|improve this answer



















  • 7




    Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
    – TrueWill
    Jan 15 '15 at 16:21






  • 1




    Should it be source.ForEach(destination.Add) ?
    – Frank
    Sep 8 '16 at 20:04












  • @Frank Hi Frank, fixed thanks for noticing :)
    – Matas Vaitkevicius
    Sep 9 '16 at 6:30






  • 1




    ForEach seems to only be defined on List<T>, not Collection?
    – Protector one
    Jul 13 at 12:09


















up vote
18
down vote













Remember that each Add will check the capacity of the collection and resize it whenever necessary (slower). With AddRange, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.






share|improve this answer



















  • 3




    To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
    – Nick Udell
    Sep 22 '14 at 9:58


















up vote
1
down vote













The C5 Generic Collections Library classes all support the AddRange method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic ICollection and IList interfaces, meaning that C5's collections can be easily substituted as the underlying implementation.






share|improve this answer




























    up vote
    0
    down vote













    You could add your IEnumerable range to a list then set the ICollection = to the list.



            IEnumerable<T> source;

    List<item> list = new List<item>();
    list.AddRange(source);

    ICollection<item> destination = list;





    share|improve this answer

















    • 3




      While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
      – Nick Udell
      Sep 22 '14 at 9:56


















    up vote
    0
    down vote













    Or you can just make an ICollection extension like this:



     public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
    {
    foreach(var item in items)
    {
    @this.Add(item);
    }

    return @this;
    }


    Using it would be just like using it on a list:



    collectionA.AddRange(IEnumerable<object> items);





    share|improve this answer





















      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














       

      draft saved


      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1474863%2faddrange-to-a-collection%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      7 Answers
      7






      active

      oldest

      votes








      7 Answers
      7






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      48
      down vote



      accepted










      No, this seems perfectly reasonable. There is a List<T>.AddRange() method that basically does just this, but requires your collection to be a concrete List<T>.






      share|improve this answer





















      • Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
        – TrueWill
        Sep 25 '09 at 0:52






      • 4




        Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
        – Reed Copsey
        Sep 25 '09 at 1:12















      up vote
      48
      down vote



      accepted










      No, this seems perfectly reasonable. There is a List<T>.AddRange() method that basically does just this, but requires your collection to be a concrete List<T>.






      share|improve this answer





















      • Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
        – TrueWill
        Sep 25 '09 at 0:52






      • 4




        Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
        – Reed Copsey
        Sep 25 '09 at 1:12













      up vote
      48
      down vote



      accepted







      up vote
      48
      down vote



      accepted






      No, this seems perfectly reasonable. There is a List<T>.AddRange() method that basically does just this, but requires your collection to be a concrete List<T>.






      share|improve this answer












      No, this seems perfectly reasonable. There is a List<T>.AddRange() method that basically does just this, but requires your collection to be a concrete List<T>.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Sep 25 '09 at 0:40









      Reed Copsey

      463k579651268




      463k579651268












      • Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
        – TrueWill
        Sep 25 '09 at 0:52






      • 4




        Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
        – Reed Copsey
        Sep 25 '09 at 1:12


















      • Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
        – TrueWill
        Sep 25 '09 at 0:52






      • 4




        Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
        – Reed Copsey
        Sep 25 '09 at 1:12
















      Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
      – TrueWill
      Sep 25 '09 at 0:52




      Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
      – TrueWill
      Sep 25 '09 at 0:52




      4




      4




      Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
      – Reed Copsey
      Sep 25 '09 at 1:12




      Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
      – Reed Copsey
      Sep 25 '09 at 1:12












      up vote
      29
      down vote













      Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.



      public static void AddRange<T>(this ICollection<T> destination,
      IEnumerable<T> source)
      {
      List<T> list = destination as List<T>;

      if (list != null)
      {
      list.AddRange(source);
      }
      else
      {
      foreach (T item in source)
      {
      destination.Add(item);
      }
      }
      }





      share|improve this answer



















      • 2




        The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
        – rymdsmurf
        Oct 29 '14 at 12:04






      • 3




        arrgggh! Swap the condition branches, for the love of all that's holy!
        – nicodemus13
        Jul 15 '16 at 16:11






      • 9




        I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
        – nicodemus13
        Jul 20 '16 at 7:42






      • 9




        Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
        – rymdsmurf
        Jul 25 '16 at 9:39






      • 3




        Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
        – Jacob Foshee
        Sep 1 '17 at 21:47















      up vote
      29
      down vote













      Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.



      public static void AddRange<T>(this ICollection<T> destination,
      IEnumerable<T> source)
      {
      List<T> list = destination as List<T>;

      if (list != null)
      {
      list.AddRange(source);
      }
      else
      {
      foreach (T item in source)
      {
      destination.Add(item);
      }
      }
      }





      share|improve this answer



















      • 2




        The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
        – rymdsmurf
        Oct 29 '14 at 12:04






      • 3




        arrgggh! Swap the condition branches, for the love of all that's holy!
        – nicodemus13
        Jul 15 '16 at 16:11






      • 9




        I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
        – nicodemus13
        Jul 20 '16 at 7:42






      • 9




        Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
        – rymdsmurf
        Jul 25 '16 at 9:39






      • 3




        Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
        – Jacob Foshee
        Sep 1 '17 at 21:47













      up vote
      29
      down vote










      up vote
      29
      down vote









      Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.



      public static void AddRange<T>(this ICollection<T> destination,
      IEnumerable<T> source)
      {
      List<T> list = destination as List<T>;

      if (list != null)
      {
      list.AddRange(source);
      }
      else
      {
      foreach (T item in source)
      {
      destination.Add(item);
      }
      }
      }





      share|improve this answer














      Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.



      public static void AddRange<T>(this ICollection<T> destination,
      IEnumerable<T> source)
      {
      List<T> list = destination as List<T>;

      if (list != null)
      {
      list.AddRange(source);
      }
      else
      {
      foreach (T item in source)
      {
      destination.Add(item);
      }
      }
      }






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Oct 14 '14 at 14:20









      TrueWill

      19.5k673120




      19.5k673120










      answered Oct 14 '14 at 11:44









      rymdsmurf

      450410




      450410








      • 2




        The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
        – rymdsmurf
        Oct 29 '14 at 12:04






      • 3




        arrgggh! Swap the condition branches, for the love of all that's holy!
        – nicodemus13
        Jul 15 '16 at 16:11






      • 9




        I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
        – nicodemus13
        Jul 20 '16 at 7:42






      • 9




        Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
        – rymdsmurf
        Jul 25 '16 at 9:39






      • 3




        Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
        – Jacob Foshee
        Sep 1 '17 at 21:47














      • 2




        The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
        – rymdsmurf
        Oct 29 '14 at 12:04






      • 3




        arrgggh! Swap the condition branches, for the love of all that's holy!
        – nicodemus13
        Jul 15 '16 at 16:11






      • 9




        I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
        – nicodemus13
        Jul 20 '16 at 7:42






      • 9




        Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
        – rymdsmurf
        Jul 25 '16 at 9:39






      • 3




        Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
        – Jacob Foshee
        Sep 1 '17 at 21:47








      2




      2




      The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
      – rymdsmurf
      Oct 29 '14 at 12:04




      The as operator will never throw. If destination cannot be cast, list will be null and the else block will execute.
      – rymdsmurf
      Oct 29 '14 at 12:04




      3




      3




      arrgggh! Swap the condition branches, for the love of all that's holy!
      – nicodemus13
      Jul 15 '16 at 16:11




      arrgggh! Swap the condition branches, for the love of all that's holy!
      – nicodemus13
      Jul 15 '16 at 16:11




      9




      9




      I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
      – nicodemus13
      Jul 20 '16 at 7:42




      I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
      – nicodemus13
      Jul 20 '16 at 7:42




      9




      9




      Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
      – rymdsmurf
      Jul 25 '16 at 9:39




      Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
      – rymdsmurf
      Jul 25 '16 at 9:39




      3




      3




      Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
      – Jacob Foshee
      Sep 1 '17 at 21:47




      Pattern matching will make everyone happy... ;-) if (destination is List<T> list)
      – Jacob Foshee
      Sep 1 '17 at 21:47










      up vote
      19
      down vote













      Since .NET4.5 if you want one-liner you can use System.Collections.Generic ForEach.



      source.ForEach(o => destination.Add(o));


      or even shorter as



      source.ForEach(destination.Add);


      Performance-wise it's same as for each loop (syntactic sugar).



      Also don't try assigning it like



      var x = source.ForEach(destination.Add) 


      cause ForEach is void.






      share|improve this answer



















      • 7




        Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
        – TrueWill
        Jan 15 '15 at 16:21






      • 1




        Should it be source.ForEach(destination.Add) ?
        – Frank
        Sep 8 '16 at 20:04












      • @Frank Hi Frank, fixed thanks for noticing :)
        – Matas Vaitkevicius
        Sep 9 '16 at 6:30






      • 1




        ForEach seems to only be defined on List<T>, not Collection?
        – Protector one
        Jul 13 at 12:09















      up vote
      19
      down vote













      Since .NET4.5 if you want one-liner you can use System.Collections.Generic ForEach.



      source.ForEach(o => destination.Add(o));


      or even shorter as



      source.ForEach(destination.Add);


      Performance-wise it's same as for each loop (syntactic sugar).



      Also don't try assigning it like



      var x = source.ForEach(destination.Add) 


      cause ForEach is void.






      share|improve this answer



















      • 7




        Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
        – TrueWill
        Jan 15 '15 at 16:21






      • 1




        Should it be source.ForEach(destination.Add) ?
        – Frank
        Sep 8 '16 at 20:04












      • @Frank Hi Frank, fixed thanks for noticing :)
        – Matas Vaitkevicius
        Sep 9 '16 at 6:30






      • 1




        ForEach seems to only be defined on List<T>, not Collection?
        – Protector one
        Jul 13 at 12:09













      up vote
      19
      down vote










      up vote
      19
      down vote









      Since .NET4.5 if you want one-liner you can use System.Collections.Generic ForEach.



      source.ForEach(o => destination.Add(o));


      or even shorter as



      source.ForEach(destination.Add);


      Performance-wise it's same as for each loop (syntactic sugar).



      Also don't try assigning it like



      var x = source.ForEach(destination.Add) 


      cause ForEach is void.






      share|improve this answer














      Since .NET4.5 if you want one-liner you can use System.Collections.Generic ForEach.



      source.ForEach(o => destination.Add(o));


      or even shorter as



      source.ForEach(destination.Add);


      Performance-wise it's same as for each loop (syntactic sugar).



      Also don't try assigning it like



      var x = source.ForEach(destination.Add) 


      cause ForEach is void.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Sep 9 '16 at 6:32

























      answered Jan 15 '15 at 15:17









      Matas Vaitkevicius

      32k15160170




      32k15160170








      • 7




        Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
        – TrueWill
        Jan 15 '15 at 16:21






      • 1




        Should it be source.ForEach(destination.Add) ?
        – Frank
        Sep 8 '16 at 20:04












      • @Frank Hi Frank, fixed thanks for noticing :)
        – Matas Vaitkevicius
        Sep 9 '16 at 6:30






      • 1




        ForEach seems to only be defined on List<T>, not Collection?
        – Protector one
        Jul 13 at 12:09














      • 7




        Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
        – TrueWill
        Jan 15 '15 at 16:21






      • 1




        Should it be source.ForEach(destination.Add) ?
        – Frank
        Sep 8 '16 at 20:04












      • @Frank Hi Frank, fixed thanks for noticing :)
        – Matas Vaitkevicius
        Sep 9 '16 at 6:30






      • 1




        ForEach seems to only be defined on List<T>, not Collection?
        – Protector one
        Jul 13 at 12:09








      7




      7




      Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
      – TrueWill
      Jan 15 '15 at 16:21




      Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
      – TrueWill
      Jan 15 '15 at 16:21




      1




      1




      Should it be source.ForEach(destination.Add) ?
      – Frank
      Sep 8 '16 at 20:04






      Should it be source.ForEach(destination.Add) ?
      – Frank
      Sep 8 '16 at 20:04














      @Frank Hi Frank, fixed thanks for noticing :)
      – Matas Vaitkevicius
      Sep 9 '16 at 6:30




      @Frank Hi Frank, fixed thanks for noticing :)
      – Matas Vaitkevicius
      Sep 9 '16 at 6:30




      1




      1




      ForEach seems to only be defined on List<T>, not Collection?
      – Protector one
      Jul 13 at 12:09




      ForEach seems to only be defined on List<T>, not Collection?
      – Protector one
      Jul 13 at 12:09










      up vote
      18
      down vote













      Remember that each Add will check the capacity of the collection and resize it whenever necessary (slower). With AddRange, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.






      share|improve this answer



















      • 3




        To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
        – Nick Udell
        Sep 22 '14 at 9:58















      up vote
      18
      down vote













      Remember that each Add will check the capacity of the collection and resize it whenever necessary (slower). With AddRange, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.






      share|improve this answer



















      • 3




        To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
        – Nick Udell
        Sep 22 '14 at 9:58













      up vote
      18
      down vote










      up vote
      18
      down vote









      Remember that each Add will check the capacity of the collection and resize it whenever necessary (slower). With AddRange, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.






      share|improve this answer














      Remember that each Add will check the capacity of the collection and resize it whenever necessary (slower). With AddRange, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Oct 2 '12 at 10:30









      jonsca

      8,483114756




      8,483114756










      answered Aug 20 '12 at 14:50









      jvitor83

      308417




      308417








      • 3




        To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
        – Nick Udell
        Sep 22 '14 at 9:58














      • 3




        To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
        – Nick Udell
        Sep 22 '14 at 9:58








      3




      3




      To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
      – Nick Udell
      Sep 22 '14 at 9:58




      To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
      – Nick Udell
      Sep 22 '14 at 9:58










      up vote
      1
      down vote













      The C5 Generic Collections Library classes all support the AddRange method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic ICollection and IList interfaces, meaning that C5's collections can be easily substituted as the underlying implementation.






      share|improve this answer

























        up vote
        1
        down vote













        The C5 Generic Collections Library classes all support the AddRange method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic ICollection and IList interfaces, meaning that C5's collections can be easily substituted as the underlying implementation.






        share|improve this answer























          up vote
          1
          down vote










          up vote
          1
          down vote









          The C5 Generic Collections Library classes all support the AddRange method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic ICollection and IList interfaces, meaning that C5's collections can be easily substituted as the underlying implementation.






          share|improve this answer












          The C5 Generic Collections Library classes all support the AddRange method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic ICollection and IList interfaces, meaning that C5's collections can be easily substituted as the underlying implementation.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 5 '09 at 18:26









          Marcus Griep

          5,41211723




          5,41211723






















              up vote
              0
              down vote













              You could add your IEnumerable range to a list then set the ICollection = to the list.



                      IEnumerable<T> source;

              List<item> list = new List<item>();
              list.AddRange(source);

              ICollection<item> destination = list;





              share|improve this answer

















              • 3




                While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
                – Nick Udell
                Sep 22 '14 at 9:56















              up vote
              0
              down vote













              You could add your IEnumerable range to a list then set the ICollection = to the list.



                      IEnumerable<T> source;

              List<item> list = new List<item>();
              list.AddRange(source);

              ICollection<item> destination = list;





              share|improve this answer

















              • 3




                While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
                – Nick Udell
                Sep 22 '14 at 9:56













              up vote
              0
              down vote










              up vote
              0
              down vote









              You could add your IEnumerable range to a list then set the ICollection = to the list.



                      IEnumerable<T> source;

              List<item> list = new List<item>();
              list.AddRange(source);

              ICollection<item> destination = list;





              share|improve this answer












              You could add your IEnumerable range to a list then set the ICollection = to the list.



                      IEnumerable<T> source;

              List<item> list = new List<item>();
              list.AddRange(source);

              ICollection<item> destination = list;






              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Aug 22 '14 at 5:49









              Jonathan Jansen

              1238




              1238








              • 3




                While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
                – Nick Udell
                Sep 22 '14 at 9:56














              • 3




                While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
                – Nick Udell
                Sep 22 '14 at 9:56








              3




              3




              While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
              – Nick Udell
              Sep 22 '14 at 9:56




              While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
              – Nick Udell
              Sep 22 '14 at 9:56










              up vote
              0
              down vote













              Or you can just make an ICollection extension like this:



               public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
              {
              foreach(var item in items)
              {
              @this.Add(item);
              }

              return @this;
              }


              Using it would be just like using it on a list:



              collectionA.AddRange(IEnumerable<object> items);





              share|improve this answer

























                up vote
                0
                down vote













                Or you can just make an ICollection extension like this:



                 public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
                {
                foreach(var item in items)
                {
                @this.Add(item);
                }

                return @this;
                }


                Using it would be just like using it on a list:



                collectionA.AddRange(IEnumerable<object> items);





                share|improve this answer























                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  Or you can just make an ICollection extension like this:



                   public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
                  {
                  foreach(var item in items)
                  {
                  @this.Add(item);
                  }

                  return @this;
                  }


                  Using it would be just like using it on a list:



                  collectionA.AddRange(IEnumerable<object> items);





                  share|improve this answer












                  Or you can just make an ICollection extension like this:



                   public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
                  {
                  foreach(var item in items)
                  {
                  @this.Add(item);
                  }

                  return @this;
                  }


                  Using it would be just like using it on a list:



                  collectionA.AddRange(IEnumerable<object> items);






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 9 at 10:53









                  Katarina Kelam

                  11




                  11






























                       

                      draft saved


                      draft discarded



















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1474863%2faddrange-to-a-collection%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Schultheiß

                      Verwaltungsgliederung Dänemarks

                      Liste der Kulturdenkmale in Wilsdruff