2

What is the limitation of 

public class A
{
     public string Stuff {get;set;}
}

...

repository.GetAll().Select(x=> new A { x.Stuff });

That doesn't work. You have to add 

{ Stuff = x.Stuff }

repository.GetAll().Select(x=> new { x.Stuff });

But this works. It creates an anon class with a very similar definition to class A.

Conceptually I don't see a big difference in what is going on here. Anyone shed some light?

Steve
  • 25,806
  • 2
  • 33
  • 43
  • 3
    What if the types of `x.Stuff` and `A.Stuff` differ? What if one is implicitly convertible to the other? On the other hand, you will never run into such a problem for anonymous types because those types are created at the moment of initialization, whereby the member names *and* types are simply taken from the properties you pass into the initializer on creation of the anon type. – BoltClock May 23 '12 at 17:26
  • That wasn't my downvote by the way. Just to let you know. – BoltClock May 23 '12 at 17:27
  • good point @BoltClock thats probably a good enough reason to disallow it. – Steve May 23 '12 at 17:27

2 Answers2

3

The short answer - the C# compiler and language team didn't implement it this way - they either didn't think of it (unlikely) or decided that it was not a good idea....

repository.GetAll().Select(x=> new A { x.Stuff });

That doesn't work. You have to add

This is an object initializer. This works by calling the default constructor on an object, and then matching property names to a value, ie: Stuff = x.Foo, and is really just a shortcut for matching properties, so the syntax is really just "short hand" for:

A tmp = new A();
tmp.Stuff = x.Stuff;

Now, I suppose the compiler team could have assumed that an initialization statement with no left hand side on the equation should search for a matching property where the name matched and the type was implicitly convertible, but I suspect this would fall into the realm of "flirting with the bad idea list" if or when it would've been discussed by the language team. In general, C# is fairly explicit in its syntax, and this would be loosening that up a bit in a way that requires two separate matches (name + type) and would be non-obvious in many scenarios. Since you're working with a public API here (A), it'd also be very easy for a refactoring in either side (A or whatever type "x" is defined as being) to break this completely.

Finally, this also isn't really necessary - if you want an instance of A to be constructed this way, just add a constructor with an overload (which is safer in many ways in any case), and use:

repository.GetAll().Select(x=> new A(x.Stuff));

This makes the intention and meaning very explicit, and takes out the brittle maintainability.

repository.GetAll().Select(x=> new { x.Stuff });

This is doing something completely different - here, you're initializing an anonymous type, and letting the compiler completely determine the type names and types for you. I suspect this was determined to be "safe" since you're never really working with a public API - anonymous types aren't really supposed to "leak" out of the method where it's defined. The risk of having a refactoring change a property name and effectively change values, etc, gets dramatically reduced and isolated to a single method in this case, which in turn keeps this "automatic" naming feature lower risk overall. Also, there isn't an easy alternative here, as you can't define constructors on anonymous types, so there wouldn't be a simple way to have a concise syntax in this case. This adds benefit without introducing a lot of risk.

Community
  • 1
  • 1
Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • yeah i just don't like selecting * on an entity, and can't really use an anon to pass around functions like you mentioned with the result of a query. So I've been selecting only the properties i'm using on the entity to reduce bandwidth. creating a constructor for all the permutations doesn't fit the scenario so i'll stick with the initializer even though it is a little more brittle. – Steve May 23 '12 at 17:42
  • @Steve The danger there, though, is that you're making entity types that are effectively "invalid" or wrong, since they're incomplete. This is typically a very bad idea... – Reed Copsey May 23 '12 at 18:40
  • I have to disagree there, but I understand your reasoning. What would you suggest that wouldn't add lots of cruft? – Steve May 23 '12 at 19:11
  • @Steve It really depends on the use case - but small DTOs are common in this type of scenario. – Reed Copsey May 23 '12 at 19:26
  • sounds like cruft. especially if you don't want your dto's to be invalid or wrong you'll have to have a shiload of them for the same reasons we started this digression. – Steve May 23 '12 at 19:33
  • this looks like an interesting approach: http://www.devtrends.co.uk/blog/stop-using-automapper-in-your-data-access-code – Steve May 24 '12 at 15:42
1

One possible reasoning: if implicit property assignment would be allowed for real types than change in item of repository (i.e. x.Stuff renamed to x.Other) would cause compile time error in very surprising place as new property no longer match A.Stuff.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • I would imagine that is something the compiler could warn you about, and if you change schema's you should expect to fix issues across your code base. – Steve May 23 '12 at 17:32
  • Reed's answer covers it much better. Note that compiler have no knowledge about semantic of your classes, so you need to consider such question in very generic sense - "for any place where anonymous class can be created ...". – Alexei Levenkov May 23 '12 at 18:12