In Foof We Trust: A Dialogue

In Foof We Trust: A Dialogue

Rate This
  • Comments 53

User: The typeof(T) operator in C# essentially means “compiler, generate some code that gives me an object at runtime which represents the type you associate with the name T”. It would be nice to have similar operators that could take names of, say, methods and give you other metadata objects, like method infos, property infos, and so on. This would be a more pleasant syntax than passing ugly strings and types and binding flags to various Reflection APIs to get that information.

Eric: I agree, that would be a lovely sugar. This idea has been coming up during the C# design meeting for almost a decade now. We call the proposed operator “infoof”, since it would return arbitrary metadata info. We whimsically insist that it be pronounced “in-foof”, not “info-of”.

User: So implement it already, if you’ve been getting requests for the better part of ten years! What are you waiting for?

Eric: First, as I’ve discussed before on my blog, we have a very limited time and money budget for design, implementation, testing, documentation and maintenance, so we want to make sure we’re spending it on the highest-value features. This one has never made it over that bar.

Second, the feature seems at first glance to be simple, but in fact has a rather large “design surface” and would require adding a fair amount of new syntax to the language.

Third, it is nothing that you cannot do already with existing code; it’s not necessary, it’s just nice.

All these are enough “points against” the feature that it’s never made it into positive territory. It will stay on the list for hypothetical future versions of the language, but I would not expect it to ever happen.

User: Can you elaborate on some of the problems?

Eric: Let’s start with a simple one. Suppose you have infoof(Bar) where Bar is an overloaded method. Suppose there is a specific Bar that you want to get info for. This is an overload resolution problem. How do you tell the overload resolution algorithm which one to pick? The existing overload resolution algorithm requires either argument expressions or, at the very least, argument types.

Expressions seem problematic. Either they are evaluated unnecessarily, perhaps producing unwanted side effects, or you have a bunch of expressions in code that looks like a function call but isn’t actually. Either way is potentially confusing. So we’d want to stick with types.

User: Well then, it ought to be straightforward then. infoof(Bar(int, int)), done.

Eric: I notice that you’ve just introduced new syntax; nowhere in C# previously did we have a parenthesized, comma-separated list of types. But that’s not at all hard to parse.

User: Exactly. So go with that.

Eric: OK smart guy, what about this strangely familiar case?

class C<T>
{
  public void Bar(int x, T y) {}
  public void Bar(T x, int y) {}
  public void Bar(int x, int y) {}
}
class D : C<int>
{ …

You have some code in D that says infoof(Bar(int, int)). There are three candidates. Which do you pick?

User: Well, which would overload resolution pick if you called Bar(10, 10) ? Overload resolution tiebreaker rules say to pick the non-generic version when faced with this awful situation.

Eric: Great. Except that’s not the one I wanted. I wanted the method info of the second version. If your proposed syntax picks one of them then you need to give me a syntax to pick the others.

User: Hmm. It's hard because overload resolution actually gives you no way to force the call to go to one of the two “generic param” methods in this bizarre case, so some mechanism stronger than overload resolution needs to be invented if you want the feature to allow getting info of any method.

But this is a deliberately contrived corner case; just cut it. You don’t have to support this scenario.

Eric: And now you start to see how this always goes in the design meeting! It is very easy to design a feature that hits what initially looks like 80% of the cases. And then you discover that the other 80% of the cases are not covered, and the feature either takes 160% of its budget, or you end up with a confusing, inconsistent and weak feature, or, worse, both.

And how do we know what scenarios to cut? We have to design a feature that does something in every possible case, even if that something is an error. So we have to at least spend the time to consider every possible case during the design. There are a lot of weird cases to consider!

User: What are some of the other weird cases?

Eric: Just off the top of my head, here are a few. (1) How do you unambiguously specify that you want a method info of an specific explicit interface implementation? (2) What if overload resolution would have skipped a particular method because it is not accessible? It is legal to get method infos of methods that are not accessible; metadata is always public even if it describes private details. Should we make it impossible to get private metadata, making the feature weak, or should we make it possible, and make infoof use a subtly different overload resolution algorithm than the rest of C#?  (3) How do you specify that you want the info of, say, an indexer setter, or a property getter, or an event handler adder?

There are lots more goofy edge cases.

User: I’m sure that we could come up with a syntax for all of those cases.

Eric: Sure. None of these problems are unsolvable. But they almost all require careful design and new syntax, and we would soon end up spending most of our design, implementation and testing budget on this trivial “sugar” feature, budget that we could be spending on more valuable features that solve real problems.

User: Well, how about you do the easy 80% and make “the other 80%” into error cases? Sure, the smaller feature is weaker and might be inconsistent, but something is better than nothing, and it’ll be cheaper to just do the easy ones.

Eric: That doesn’t actually make it cheaper a lot of the time. Any time we make a corner case into an error we need to carefully specify exactly what the error case is so that we can implement it correctly and test it confidently. Every error case still spends design, implementation and test budget that could have been spent elsewhere.

We would need to come up with a sensible error message, localize the error message into I don’t know how many languages, implement the code that detects the weird scenarios and gives the right error, test the error cases and document them. And we would need to deal with all the users who push back on each error case and request that it work for their specific scenario.

Trying to scope the feature down so that it is smaller adds work, and it is possible that it adds more work in the long run than simply making the larger version of the feature work in the first place. There are no cheap features.

User: Bummer. Because most of the time I really just want to get the method info of the method I’m currently running, for logging purposes during my test suites. It seems a shame to have to solve all these overload resolution problems just to get information about what’s happening at runtime.

Eric: Maybe you should have said that in the first place! The aptly named GetCurrentMethod method does that.

User: So what you’re telling me is no infoof?

Eric: It’s an awesome feature that pretty much everyone involved in the design process wishes we could do, but there are good practical reasons why we choose not to. If there comes a day when designing it and implementing it is the best way we could spend our limited budget, we’ll do it. Until then, use Reflection.

  • I'd far rather have more metaprogramming-like features such as expression trees than an improvement on reflection. I don't see why people would want infoof over named and optional parameters and especially co- and contravariance. I have want for those features almost in every project, while I only felt the need to use reflection once or twice.

  • Thank you Eric for your explanations, now I can sleep well :)

    When I was talking about "not realistic" example I just meant that this feature is something different, e.g. there are several logging frameworks that write down caller name (via reflection, I don't think infoof will help such frameworks) and it takes a few minutes to google the solution.

    Of course it's definitely better to specify attributes with say MethodInfo instead of method names but I was just wondering if infoof returns MethodInfo how can it be converted to string at compile time to coexist with the way things are done now (this is actually a week feature, it's already there and we have to live with it). I believe you have the answer but from my point of view it's a real challenge to combine these two worlds and I can only hope you found a way to do it.

  • Two observations:

    "It is very easy to design a feature that hits what initially looks like 80% of the cases. And then you discover that the other 80% of the cases are not covered, "

    How can both be 80%? Am I missing something here? It should be '80% of the cases, and then you discover that the other 20% of the cases are not covered'.

    It's a joke. You get through what you THINK are 80% of the cases, you've spent 80% of your budget on them, and then you discover that in fact you are only half done. In that scenario you are going to either ship a half-done feature, or you're going to spend 160% of your budget. Hence the joke. -- Eric

    Secondly, are you sure your example

    class C<T>

     public void Bar(int x, T y) {}
     public void Bar(T x, int y) {}  
     public void Bar(int x, int y) {}
    }
    class D : C<int>
    { …

    is correct given this: http://blogs.msdn.com/samng/archive/2008/02/13/generic-method-substitutions-and-unification.aspx and http://blogs.msdn.com/samng/archive/2008/03/04/generic-method-substitutions-and-unification-part-two.aspx ?

    Indeed, as Sam's blog notes, this is a case where what is allowed by the C# language and what is allowed by the CLR are different. We're still trying to figure out what the right resolution is; until we do, I strongly recommend that you avoid situations like this. -- Eric

  • @pminaev's verbose option is pretty much what I've had in mind whenever I think about this feature because there are just so many edge cases.  Even if some lightweight sugary syntax is provided for simple non-overloaded members, there needs to be an unambiguous specification available.

    Even so some cases like explicit interface implementations would be tortuously difficult to specify and probably shouldn't be supported at all since they just aren't useful enough.  Either that or we would need to provide syntax like:  infoof(IEnumerator List<T>.(System.IEnumerable.GetEnumerator())) with some goofy parentheses to escape the explicit member name.  But really?

    That makes me wonder what the visibility rules should be...   I imagine that for safety and consistency reasons we should use ordinary visibility rules governing member access in lexical scopes.  In that case, references to explicit interface implementations are right out since we can't even refer to the explicit members within their own implementation!  (good riddance)

    Obviously the syntax does need to support the keyword escaping mechanism: infoof(string MyType.@namespace) assuming we have a field called namespace.  This presents no new challenges to the language.

    Indexers are pretty easy: infoof(object MyType.Item[int]).  Of course Item doesn't appear in the C# language anywhere else so this leaks implementation details.  So we could use infoof(object MyType.this[int]) I suppose.  *cringe*

    Referring to get / set / add / remove / raise methods is kind of pointless but not hard.  We could adopt the usual prefix naming convention: infoof(string MyType.get_Property()).  Indexed property accessor methods follow similarly.  The prefixes leak through reflection anyways so they aren't exactly hidden implementation details.

    Another question is whether infoof should accept types or whether that should remain the domain of typeof.  My intuition is to that infoof should only provide references to non-type members because otherwise we have an ambiguity in the case where a type T has a property called T.  Using typeof(T) correctly resolves the type.  Using infoof(object T.T) should get the property.  If we provide a lightweight syntax for non-overloaded members, then infoof(T) should also get the property.

    Constructors and finalizers aren't hard: infoof(MyType(int)), infoof(~MyType()).  It should be noted that the parentheses must not be omitted from constructor signatures.

    As long as we use full names for everywhere then there isn't much potential ambiguity.  The problems start when we extend the syntax to allow specification of non-overloaded members with a short form name... so we might do well to just leave that option out!

    Has anyone attempted to work out a full detailed proposal for infoof, its variations and ramifications?  Would it be of use if someone in the community produced such a proposal?

    Anyways, my main use-case driving this is for use in attributes but there are also quite a few cases, particularly for testing, where static binding to a member reference is required.  Delegates and expression trees are cumbersome are of limited utility for some scenarios.

    I do recognized that matter how this feature is scoped 'infoof' will be a lot of work for compiler and downstream tool writers.  I know quite a few tools that will probably barf when presented with attributes that contain member tokens that are not types.  I hope that someday a reasonable variation of this idea will appear in the language since it will greatly benefit static metaprogramming.

    Of course, someday I'd also like to see the custom attribute blobs sprout the ability to express recursive data structures besides arrays similar to Java annotations.  :-)

    *wish* *wish* *wish*

  • Fair enough, up to a point.

    What I've wished for many a time (and I don't think I'm alone) is a nameof operator I can use with method arguments so as to populate the ArgumentException's parameter in such a way that it is type-safe + refactor-safe. Getting full ParameterInfo metadata would be a bonus of course, but not required to be useful.

    I struggle to think when nameof(argument) (or infoof(argument) for that matter) could ever have an edgecase associated with it, but I agree this would be (in your terms ) a 'week' feature in that it would only work within the scope of the method that has the arguments.

    [in the rest of the world we call this incremental delivery: solve the easy problems first, and come back to the hard ones if you have time]

    Note that a more general 'nameof' operator skips your overload resolution problem, since *it doesn't do any* : you still need to pass the output from nameof to a reflection API *along with bindingflags, args etc...* to resolve to a method. It just saves you from littering your codebase with strings that you already put in the codebase once (as method/property/argument identifiers) and struggle to see why you should have to duplicate.

  • @piers7: if it does not do any overload resolution, how can it be refactoring-safe?

    i.e., if there are several overloads, and one of them gets renamed, will the reference in nameof be renamed too?

    I thought of a similar mechanism (in presence of several overloads, just return all of them, so methodof() would always return an array). same problem though. there is just no concept of referencing a name in C#, so anything would probaby be cumbersome.

    as for the argument checks: 1) argument names have no runtime representation, so this would be an entirely different feature, and 2) how bad is this really? I believe a VS code snippet will solve this problem quite well. the argument name does not follow refactorings, but how often does such a mistake happen, and how often is this really a problem? (most of the times, it will still be clear which argument caused the problem, unless you actually swapped names)

    @Eric

    a few other ideas:

    - explicit interface implementations: just don't support them. you can use infoof to get the interface member straight from the interface and go from there.

    - getting getters/setters and adders/removers: just let us have the PropertyInfo/EventInfo, they have methods to get to those values

    - indexers and operators: pretty uninteresting. the kinds of operators are easily available, so they can be retreived using a library (MyUtil.GetIndexer (Type t)).

    I would not consider an implementation that does not have any of those above weak.

    - private members: just be consistent with typeof and disallow access

    overloads and generics are tricky though, granted.

    the problem is that if you don't give us infoof, we'll have to take care of overload resolution ourselves, on a library level. which is worse.

    in any case I think the expression tricks used to extract MemberInfos from lambda-expressions would be good enough. the only problem here is that we cannot use them where we'd need them most: in attributes.

    so I think I'll give you the point about infoof and rather than keep on discussing stuff that is already decided, ask for a different one:

    Remove C# attribute restrictions, including generics and argument types

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=425856

    The funny part is that the first part of this request (generics) would actually be _really_ easy to implement, something that's not supposed to be true for any language feature. (but that's only because everything is already in place and you would just need to remove an unnecessary error check)

    Anyway, thanks for the great explanation. I admit that I've been in the "how hard can it be" camp, but I don't have any good answer to the generic overload question except "don't support", but in this case I understand why you'd rather not do that.

  • > private members: just be consistent with typeof and disallow access

    typeof() does not disallow access to private types, if the code that uses it has access to them.

  • @pminaev Eric wrote "(2) What if overload resolution would have skipped a particular method because it is not accessible? It is legal to get method infos of methods that are not accessible; metadata is always public even if it describes private details. Should we make it impossible to get private metadata, making the feature weak, or should we make it possible, and make infoof use a subtly different overload resolution algorithm than the rest of C#?"

    I think in the context of the question the comment makes sense.

    BTW, making infoof able to access members that would otherwise be unaccessible would be a dangerous feature anyway. there should not be any hard-coded references to private members of other assemblies in any case, and doing it via reflection wouldn't make it any better. stuff is private for a reason. we should only access private members via reflection if they are dynamically discovered, as in a serializer.

    but the whole discussion is moot anyway. we're not going to get it.

  • If you don't read Eric Lippert's Fabulous Adventures In Coding , you're really missing out on some great

  • If you don&#39;t read Eric Lippert&#39;s Fabulous Adventures In Coding , you&#39;re really missing out

  • Indeed there's a balance between usefulness and cost.

    Uniquely identifying a method is horribly complicated, probably requires a clumsy syntax, and surely adds a lot of complexity (= costs).

    At the same time I don't see many use cases for statically getting a MethodInfo. Everything I can think of is ouputting the method name in messages (e.g. logging, or assertations).

    For those scenarios GetCurrentMethod or a static aspect weaver like Post# can do wonders. And even if they break that's not my code logic that's breaking, just some outdated messages.

    I think this pretty much rules out a methodof operator, and I am fine with this.

    But please give the propertyof a chance.

    You wrote that doing only part of the feature is "weak", but is it really? In that case typeof is "weak" but I'm sure you don't want to remove it, do you?

    1. propertyof is not so expensive. Properties are relatively easy to identify: propertyof(Length), or maybe propertyof(Array.Length) when outside the class. The only slightly tricky case is indexed properties, which are unsupported in C# anyway. So the worse case left is generic types... propertyof(List<T>.Count).

    2. Ideally the compiler could infer from usage if propertyof should return a string (the property name) or a PropertyInfo instance.

    3. This would be incredibly useful! Use cases are many. We currently must write property names as string at tons of places in the framework: attributes (e.g. ItemsSourceAttribute), INotifyPropertyChanged (very common those days), DependencyProperties registration, ...

    And you know what the problem with strings is. Say hello to runtime errors because of typos, and goodbye to safe refactoring, "Find all references", etc.

    I personnally don't think your argument to justify not implementing propertyof holds... regarding infoof in its genericity, sure. But in the particular propertof case, no.

  • Пользователь: Оператор typeof(T) в C#, по существу, означает «компилятор, сгенерируй некий код, который

  • I agree completely with both Eric and James Hart.

    How about we compromise, and get a way to generate a ldtoken instruction for the current method only?

    Even better would be one that returns a RuntimeMethodHandle instead of a MethodBase, since I think the usual case is to pass it to some sort of diagnostic method that may only need to use it in rare cases where something is wrong and so in the normal case it may be able to skip the cost of constructing a MethodBase from a RuntimeMethodHandle (metadata loading, etc); but I can understand why, for consistency with the existing typeof keyword, which both ldtoken's the RuntimeTypeHandle and creates a Type for it, it might be desirable just to have it always make the MethodBase.

  • What you think about "operator .?" ?

    <object>.?<member>

    "operator .?" is equivalent of construction

    ---

    NullMemberType result;

    if (<object> != null)

     result = <object>.<member>;

    else

     result = null;

    --

    where MemberType is type of <member> result

    where NullMemberType is

     MemberType for case MemberType is class;

     MemberType for case MemberType is Nullable<T>;

     Nullable<MemberType> for case MemberType is struct

     void for case MemberType is void

    i.e. for MemberType is void - this operator is equivalent of construction

    --

    if (<object> != null)

     <object>.<member>();

    --

    this operator is very needed in script and business logic,

    and this operator is realized Null Object Pattern (http://en.wikipedia.org/wiki/Null_Object_pattern)

    example of using

    now

    --

    int? age = null;

    var root = Root;

    if (root != null)

    {

     var config = root.Config;

     if (config != null)

     {

       var user = config.User;

       if (user != null)

          age = user.Age;

     }

    }

    if (age != null && age.Value >= 21) { //bla-bla }

    --

    whit "operator .?"

    --

    if (Root.?Config.?User.?Age >= 21) {//bla-bla}

    --

    now this operator realized is very ugly as

    if (Root._no(_ => _.Config)._no(_ => _.User)._nv(_ => _.Age) >= 21) {//bla-bla}

    public static class NullableExtensions

    {

     public static void _n<TItem>(this TItem item, Action<TItem> func)

     {

       if (item != null)

         func(item);

     }

     public static TResult _no<TItem, TResult>(this TItem item, Func<TItem, TResult> func) where TResult : class

     {

       if (item == null)

         return null;

       return func(item);

     }

     public static TResult? _nv<TItem, TResult>(this TItem item, Func<TItem, TResult?> func) where TResult : struct

     {

       if (item == null)

         return null;

       return func(item);

     }

     public static TResult? _nv<TItem, TResult>(this TItem item, Func<TItem, TResult> func) where TResult : struct

     {

       if (item == null)

         return null;

       return func(item);

     }

    }

    ps

    what is better? "operator.?" or "operator?."

  • I'm confused. I was looking at some Reflector C# output for code generated by PostSharp, and it uses a "methodof" operator I'd never heard about before.

    Here's an example of the code it has generated:

    ~targetMethod~1 = methodof(SomeClass.SomeMethod);

    Is this just fictional C# syntax that Reflector has whirled up by examining what the IL is doing? The IL is:

       L_003a: ldtoken instance class [SomeAssembly]ReturnType SomeType::SomeMethod(class [SomeAssembly]SomeArgumentType, string)

       L_003f: call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle(valuetype [mscorlib]System.RuntimeMethodHandle)

    Anyone point me to some links to learn from? This isn't my area of expertise...

Page 3 of 4 (53 items) 1234