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

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

[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.

[svick]

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