This project has moved. For the latest updates, please go here.
4

Resolved

Feature request: Specify fields/property names with lambda expressions

description

Suppose I have a class like this:
public sealed class MyClass {
    private MyClass() {}

    public MyClass(string someString, int someInteger) {
        PropertyWithPrivateSetter = someString;
        _readOnlyInteger = someInteger;
    }

    public string PropertyWithPrivateSetter { get; private set; }

    private readonly int _readOnlyInteger;
    public int ReadOnlyInteger { 
        get {
            return _readOnlyInteger;
        }
    }
}
Then I can currently do the following, i.e. use strings for specifying the name of the fields and properties I want to access:

using Fasterflect;
...
        Type type = typeof (MyClass);
        object o = type.CreateInstance();
        o.SetPropertyValue("PropertyWithPrivateSetter", "Some string");
        o.SetFieldValue("_readOnlyIntegerProperty", 123);
However, I would like to see the following kind of feature which is more refactoring friendly:

o.SetPropertyValue<MyClass>(x => x.PropertyWithPrivateSetter, "Some string");
o.SetFieldValue<MyClass>(x => x.ReadOnlyInteger, Access.CamelCaseField(Prefix.Underscore), 123);

The above last example with "CamelCaseField" is based on similar feature of Fluent NHibernate, and assumes that the public property has a private field with the same name but an underscore prefix.

Now you might wonder why you would want to use reflection when you do know the class....

Well, the point is to be able to create immutable objects with private and readonly data to be used by normal application code, but providing clients of Test Builder frameworks such as NBuilder to refer to these kind of fields/properties.

For some complementing information you can also see the feature request at NBuilder:
http://code.google.com/p/nbuilder/issues/detail?id=44

/ Tomas

comments

buunguyen wrote Mar 29, 2010 at 12:23 PM

Hi Tomas, thanks for making this suggestion. Morten and I will discuss and get back with you on this.

buunguyen wrote Mar 31, 2010 at 4:39 PM

Hi Tomas, we posted a question StackOverflow about this and received a number of responses (see http://stackoverflow.com/questions/2540769/library-development-looking-for-valid-use-cases-for-suggested-feature). Do you want to have a look and see if you can add anything? As of now, we think support setting private property via lambda syntax makes sense, but not so sure about the benefit to support case of the read-only field.

mertner wrote Apr 2, 2011 at 3:48 PM

Although this could be useful in some scenarios, in order to be truly useful we would have to support a lot of naming conventions. I personally do not think the benefits outweigh the effort involved in creating and supporting this feature, but we will accept contributions to Fasterflect if someone else feels like writing the necessary code and unit tests.

dotnetchris wrote Mar 19, 2012 at 1:24 PM

This feature would have been beneficial to me, setting a private property. Clearly I got around by using the string version, but the lambda which would guarantee refactoring success would have been optimal.

mertner wrote Mar 20, 2012 at 2:53 PM

If it's any consolation, using strings will be somewhat faster as it saves extracting the member name from the expression. Also, R# has support for also renaming literal references, but you'll have to filter the suggested lists manually to avoid renaming other possible uses of the same string.

mertner wrote Apr 12, 2012 at 3:06 AM

There is actually code in Fasterflect 2.1.0 to allow you to get/set properties using lambdas:
var person = new Person( "Arthur", 32 );
Assert.AreEqual( "Arthur", person.GetPropertyValue( () => person.Name ) );
person.SetPropertyValue( () => person.Name, "Ford" );
Assert.AreEqual( "Ford", person.Name );
It's not supported for fields, but even that may show up some day ;-)

mertner wrote Apr 12, 2012 at 3:08 AM

Added in Fasterflect 2.1.0. Keeping issue open until feature has been implemented for fields. Additional overloads and documentation may also be needed.