views:

131

answers:

3

We just can use function like

public static List<T> New<T>(params T[] items) {
    return new List<T>(items);
}

and more important it's better

var list = new List<int> {1,2,3};
var list = List.New(1,2,3);

So, when we really need to use it?

Dictionary

public static Dictionary<T, K> New<T, K>(T key, K value) {
    return new Dictionary<T,K>().FAdd(key, value);
}

var dict = new Dictionary<int, string>(){
 {1, "a"},
 {2, "b"}
};

var dict = Dict.New(1,"a").FAdd(2, "b");

Why it's better, type inference

var x = new Dictionary<string, List<int>>(){
   {"a", new List<int>{1}},
   {"b", new List<int>{2}},
}

var x = Dict.New("a", List.New(1)).FAdd("b", List.New(2));
+8  A: 

This requires adding a new function in your type. Collection initializers don't require any external code in order to work - you can use them for any compatible collection type, and it's handled by the compiler automatically.

In addition, using the language functionality instead of rolling your own method will make the code more obvious to other developers. Since you're using a standard language feature, the intent becomes obvious. Using an extension method can easily mask your intent.

So, when we really need to use it?

You never need to use it. Like all language features, it's a tool - you can choose to use or to ignore, at your discretion as a developer.

Reed Copsey
I believe there is a strong correlation between idiomatic code and quality.
ChaosPandion
+7  A: 

One issue with your sample is that it's much less effecient than a collection initializer statement would be. The use of params forces the collection to essentially be created twice

  1. Once to create a .Net Array for the values
  2. Creating the actual collection

Collection initializers on the other hand just create the second collection.

Overall though one of the primary reasons for collection initializers is not having to write this API. There are a variety of collections in the framework with an unfortunate variety of creating patterns. Many don't have the constructor taking IEnumerable and instead force a set of individual Add calls. You end up writing this method over and over again.

Collection initializers let you avoid writing it altogether and instead just use the collection out of the box.

JaredPar
But but... premature optimization is the root of all evil!
ChaosPandion
@ChaosPandion: Purposeful premature de-optimization is the root of all stupidity.
Reed Copsey
If you use standard features, you automatically inherit any improvements or optimizations made to those features. This is a great reason to avoid reinventing the wheel for any software problem, unless you have a fairly compelling reason to.
Merlyn Morgan-Graham
+2  A: 

No, it is not better. Collection Initialization Syntax support any class that: 1) Has Add method 2) Implements IEnumerable. Thus it works with every collection even with Dictionary, not List only. Plus your method requires creation of array, small but excessive overhead. Initialization doesn't have it.

Andrey
I think 99% time we user list and dictionary. I don't think it's big dial have some syntax for other collections.
dotneter
@dotneter but what for? here is given universal syntax, for any present and future collections.
Andrey
type inference.
dotneter
dotneter, type inference is over rated by far, and you gain NOTHING in the case of your list implementation. And really looking at your example I see no real gain on type inference either.
Firoso
@dotneter: I agree with @Firoso. In fact, your sample makes things worse and unnecessary complex. When using a collection initializer it is immediately clear that you create e.g. a `List<uint>`, but with the extension method you suggested it isn't clear at all whether you create a `List<int>`, `List<uint>`, etc. It all depends on what kind of extension methods are defined in some far away namespace which got included at a position far away from the current line.
0xA3