infoof / propertyof / methodof (and reflection objects in attributes?)

[thebigb]

infoof is a feature that according to Eric already has been discussed internally already[1], but requires some delicacy when implemented.

I think we all understand the basic use case, that is to replace dynamic / magic reflection with a statically typed variant (with possible compile-time resolution and refactoring benefits?). Here's another idea:

When designing (theoretically) infinitely scalable systems, caching is a first-order necessity. Invalidating cache in a scalable design, however, can be quite a challenge[2]. One could manually make a dependency map to ease the pain. But who is going to do that? And who is going to maintain it? By using attributes one could quite well define dependencies between entity types, but how about we kick it up a notch and define dependencies between properties of entities? With propertyof and methodof operators (and allowing the return values to be stored in attributes) this could be achieved.

Consider the following examples:
(note that these are just a quick examples, that don't necessarily bear any use)

class Message
{
    [NotifyChanges(propertyof(Message.Followers))]
    public string Content { get; set; }

    public IEnumerable<IIdentity> Followers { get; set; }
}

class UserProfile
{
    [ReadableBy(propertyof(UserProfile.User), propertyof(User.Friends))]
    public string PhoneNumber { get; set; }

    public IIdentity User { get; set; }
}

class Group
{
    [WriteableBy(propertyof(Group.Members))]
    public string Title { get; set; }

    public IEnumerable<IIdentity> Members { get; set; }
}

Dependency mapping is a very specific use case, but you can take this into a wider perspective. The feature can be valuable to improve meta-description of your code and data entities, and I believe this could contribute to the meta-programming theme.

[1] http://blogs.msdn.com/b/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx
[2] https://stackoverflow.com/questions/1188587/cache-invalidation-is-there-a-general-solution

[tmat]

Couldn't you use nameof() feature of C# 6 to achieve the same?

[khellang]

Couldn't you use nameof() feature of C# 6 to achieve the same?

nameof is only what the name implies - the name of the argument as a string.

What @thebigb is asking for is something to get the FieldInfo/MethodInfo/PropertyInfo of the specified member, though the sample code doesn't show it very well 😄

[tmat]

Of course it gives you name. Do you need more? In the example above the consumer of the attributes could use Reflection to get the *Infos corresponding to the names.

[khellang]

Do you need more?

I think this sums it up:

that is to replace dynamic / magic reflection with a statically typed variant (with possible compile-time resolution and refactoring benefits?)

[tmat]

nameof provides compile-time resolution and refactoring benefits. The only missing piece is retrieving the runtime representation of the member (PropertyInfo). Which is no magic. Just invoke TypeInfo.GetDeclaredProperty(name).

[HaloFour]

I'm curious as to what kind of IL would be generated in each of these cases. At least with a hypothetical methodof() the IL would be nearly identical to that already generated for typeof() since each method has a unique handle and MethodBase.GetMethodFromHandle() can return a MethodBase for that handle. Fields have a similar mechanism. For properties would it have to emit out a full call to Type.GetProperty()? Also, could you differentiate between property getters v. setters?

[svick]

#1653 proposes the same feature, only with different syntax. I think one of these two proposals should be closed as duplicate.

[MadsTorgersen]

We consider nameof to be our best attempt at addressing the majority of scenarios for this feature. It doesn't get all of them, but on the other hand it can be used to get most of the rest through reflection API calls, and it is orders of magnitude less complex as a language feature.

There's also something good about keeping reflection (mostly) out of the language. You opt into it very explicitly through use of APIs.

We don't expect to go any further in this direction for the foreseeable future.