2

This post details workarounds for passing properties as references including using Expressions such as 

  public void StoreProperty(Expression<Func<T, object>> expr)

This approach is ok and I note many frameworks appear to use this (eg automapper, autofac) as detailed in James Gregory's Introduction to static reflection where he states

The great thing about this is that if you change the name of a member inside a lambda, you’ll get a compile error if you haven’t updated all the references! No more hidden bugs.

Whilst I much prefer this approach it is still not perfect as you can pass any expression returning an object (or whatever your return val is) eg 

 x => x.Name) //fine
 x => x.Name+"x")  //runtime error

Is there currently any better way to reference the property (by locking down the Expression, or some other way)

If No, how might a future version of C# lock down the Expression? for example, something like:

public void StoreProperty(Expression<Func<T, object>> expr) where expr.Member is PropertyInfo

clarification: above is only an example, I know this isn't currently supported; thats what I'm trying to discuss.

Community
  • 1
  • 1
wal
  • 17,409
  • 8
  • 74
  • 109
  • `Surely developers using your method would realize...doesn't make any sense` - I would hope so but mistakes happen. I see this as similar to type safety. Why allow any expression that returns an object when all you want is a single property? – wal Apr 04 '11 at 12:26

1 Answers1

2

Well, i don't see how it would be possible.

I wouldn't say it's "outrageous" to suggest, it's simply not the intended use. In fact this whole concept, while very useful in this situation, was not designed to answer this case. LINQ was intended as an extendable query language with a rich expression mechanism. Linq extends the language syntax to allow strong, type-safe expressions on the provided types and this is why you can use it in this way to get a strong and typesafe expression.

In this case, you are creating a function that transforms one data type (the T object) into another - a general object. If i was prohibited from writing something like p=>p.Name+"something" i would lose a lot of the inherent flexibility of the language. I.e. This would not be possible p=>p.X + p.Y as some query result that returns a sum of elements.

The solution you showed is designed to utilize a feature of linq - strong, type safe property names. It provides an elegant way of using linq to solve a problem, but like any solution - it is open to possible abuse.

A developer that passes p=>p.Name+"something" did not grok the intended use of the solution, which is a matter for training.

NightDweller
  • 913
  • 5
  • 8
  • I wasn't suggesting you prohibit something like `p=>p.Name+"something"` in all cases. Just in specific cases as detailed above. Hence my adding `where expr.Member is PropertyInfo` – wal Apr 03 '11 at 23:24
  • The expression mechanism does not know PropertyInfo. It would have been great if the language included something like: MyObject.MyProperty.PropertyInfo - but that would be outside the scope of linq. – NightDweller Apr 04 '11 at 09:23