Suggestion: nameof(xyz) operator

  • Thread starter Thread starter Jedrzej Miadowicz
  • Start date Start date
J

Jedrzej Miadowicz

I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of them
are changed by hand in code, or if the programmer onadvertently removes a
letter from one of such magic strings no one will notice until the
application is run and this very piece of code gets executed most often with
unpleasant consequences (typically some type of an ugly exception).

The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if a
typo occurred the project simply wouldn't build. Unfortunately, as things
stand right now there appears to be no way of doing this.

As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator that
the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps nameof(objectName.PropertyName),
or something similar. It seems to me that the compiler has easy access to
this type of information, or else it wouldn't be able to build my code.

If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName", true)

to look like this


new System.Windows.Forms.Binding(nameof(myTextBox.Text), someObject,
nameof(someObject.LastName), true)

and be entirely compile-time verifiable.

This same concept could be used not only in data binding but in many other
contexts where the designers currently stick literal strings. It could also
be implemented differently to return not just the name of the property or
method of a given class, but actually return the full descriptors that could
be used for further "reflection".

I would like to here some comments about this. Is there a technical reason
why such a construct cannot be added to the language?

Andrew
 
This sounds like an excellent idea, although your example is wrong. I
would expect

new System.Windows.Forms.Binding(nameof(myTextBox.Text), someObject,
nameof(someObject.LastName), true);

to be equivalent to

new System.WindowsForms.Binding("Text", someObject, "LastName", true);

Perhaps you wanted the Name of myTextBox, which you can already do like
this:

new System.WindowsForms.Binding(myTextBox.Name, someObject, "LastName",
true);

However, that still doesn't help with the object property name.

I love your idea because I have lots of object-to-control bindings, and
this would be a huge help.

Have you tried putting in this suggestion at:

http://lab.msdn.microsoft.com/productfeedback/

? When you do post it to the feedback site, post the feedback number
here, so that we can go and vote for it.
 
Jedrzej said:
I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of them
are changed by hand in code, or if the programmer onadvertently removes a
letter from one of such magic strings no one will notice until the
application is run and this very piece of code gets executed most often with
unpleasant consequences (typically some type of an ugly exception).

The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if a
typo occurred the project simply wouldn't build. Unfortunately, as things
stand right now there appears to be no way of doing this.

As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator that
the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps nameof(objectName.PropertyName),
or something similar. It seems to me that the compiler has easy access to
this type of information, or else it wouldn't be able to build my code.

If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName", true)

to look like this


new System.Windows.Forms.Binding(nameof(myTextBox.Text), someObject,
nameof(someObject.LastName), true)

and be entirely compile-time verifiable.

This same concept could be used not only in data binding but in many other
contexts where the designers currently stick literal strings. It could also
be implemented differently to return not just the name of the property or
method of a given class, but actually return the full descriptors that could
be used for further "reflection".

I would like to here some comments about this. Is there a technical reason
why such a construct cannot be added to the language?

Andrew
Click to expand...
Hm... saomething tells me that you can do this using reflection... Basicly you pass a property and
you want to get it's name as a string... i'll take a look tomorrow...
 
MuZZy said:
Hm... saomething tells me that you can do this using reflection...
Basicly you pass a property and you want to get it's name as a
string... i'll take a look tomorrow...
Click to expand...

No, you couldn't do that using reflection - if you pass the property to
something, it won't pass the PropertyInfo, it'll evaluate the property
and pass the *result* to whatever you're passing it to.
 
Jedrzej,

I think that this is a good idea. I would recommend posting it on the
product feedback center:

http://lab.msdn.microsoft.com/productfeedback/

Also, I wouldn't go with a nameof operator though, I would go with
something like infoof (read "in-foof", ha).

This would return the reflection information for whatever you passed to
it. So a method would return a MethodInfo instance, a field returns a
FieldInfo instance, etc, etc.

Then, you could do:

infoof(myTextBox.Text).Name

However, there is only one problem with this. Unless there is an IL
instruction which will get the property/method/type information really quick
(like typeof, which gets a runtime type handle), this has the potential to
slow down your code.
 
That's exactly the problem. Reflection suffers from an annoying chicken and
egg issue in that you can't find the name (or any other aspect) of a
property (or method) without knowing the name of that property in the form
of a string at runtime. What I'm referring to here is that there is no way
to get from MyClass.MyProperty to "MyProperty" other than by the developer
typing the latter by hand which is error prone. You can do it for a class
by using typeof(MyClass) and then you can find out anything you want about
the class. You can even find out about all of its properties (and methods,
and attributes, etc.) but there is no way to find out about the details of a
specific property you are interested in, unless you know its name (as in
"MyProperty") or perhaps its position in the collection of all the
properties of the class. Hard coding either one of them by hand is
dangerous. Hence, my suggestion.
 
You're right. I copied and pasted something and then tried to simplify it
and forgot to do so in one place.
 
Thanks for the suggestion. I'll make sure I post it on the feedback site.

As to whether this could be done and what performance penalty it could
incur, here's how I see it. It would be nice to get to the whole MethodInfo
or PropertyInfo instance by using this new operator. Incidentally, that's
what I meant when I mentioned property descriptors in my original post. I'm
not sure at which point these objects are created (whether it's at runtime
or compile time), but I would think they would need to begin their existence
at the same time that the class info objects are instantiated. If that's
the case the performance of the in-foof (I like the name in this form ;-))
should be no worse than that of typeof.

The whole thing could, however, be much simpler if only the name of the said
property was required. It would give the developer the same power given
that he/she could just go in with this name and use reflection to find out
anything else they need about the property. The code would be longer to do
so, but it's possible. Now, the benefit of this approach would be that if
you only needed a name (which I believe would be the most common usage) you
could get the best performance out of it. In fact, in this case the
operator could be resolved strictly at the pre-processing stage of the
compilation process (if I remember my compilers class from many years ago).
The compiler would simply need to replace nameof(MyClass.MyProperty) with
"MyProperty". It's all out there spelled out for it, and it knows what the
token MyClass.MyProperty stands for, and it fact it generates the property
info for that property into which it sticks the string "MyProperty" as the
name. Thus it could simply substitute that name for the
nameof(MyClass.MyProperty) and the deal is done. And I as a programmer
don't have to worry about typos, property name changes, etc. ever again!

Andrew

Nicholas Paldino said:
Jedrzej,

I think that this is a good idea. I would recommend posting it on the
product feedback center:

http://lab.msdn.microsoft.com/productfeedback/

Also, I wouldn't go with a nameof operator though, I would go with
something like infoof (read "in-foof", ha).

This would return the reflection information for whatever you passed to
it. So a method would return a MethodInfo instance, a field returns a
FieldInfo instance, etc, etc.

Then, you could do:

infoof(myTextBox.Text).Name

However, there is only one problem with this. Unless there is an IL
instruction which will get the property/method/type information really
quick (like typeof, which gets a runtime type handle), this has the
potential to slow down your code.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jedrzej Miadowicz said:
I recently (re)discovered data binding in Windows Forms thanks to its
advances in Visual Studio 2005. As I looked a little deeper, however, I
realize that it still suffers from an irksome tendency to stick a whole
bunch of literal strings in my code. Quite frankly, I consider them a
plague imposed on developers by the RAD designers that come with Visual
Studio. The problem with using literal strings to refer to controls, data
sources, objects, etc. and their properties is quite obvious: if any of
them are changed by hand in code, or if the programmer onadvertently
removes a letter from one of such magic strings no one will notice until
the application is run and this very piece of code gets executed most
often with unpleasant consequences (typically some type of an ugly
exception).

The problem could be completely eliminated if we could use some construct
that could be verified by the compiler at compile time. In this case if
a typo occurred the project simply wouldn't build. Unfortunately, as
things stand right now there appears to be no way of doing this.

As I thought about it some more it occurred to me that the solution
shouldn't be too hard to provide. All that is needed is a new operator
that the compiler could evaluate in very much the same fashion that
typeof(ClassName) works. I would call this operator
nameof(ClassName.PropertyName) or perhaps
nameof(objectName.PropertyName), or something similar. It seems to me
that the compiler has easy access to this type of information, or else it
wouldn't be able to build my code.

If such a construct existed I could rewrite this line:
new System.Windows.Forms.Binding("EditValue", someObject, "LastName",
true)

to look like this


new System.Windows.Forms.Binding(nameof(myTextBox.Text), someObject,
nameof(someObject.LastName), true)

and be entirely compile-time verifiable.

This same concept could be used not only in data binding but in many
other contexts where the designers currently stick literal strings. It
could also be implemented differently to return not just the name of the
property or method of a given class, but actually return the full
descriptors that could be used for further "reflection".

I would like to here some comments about this. Is there a technical
reason why such a construct cannot be added to the language?

Andrew
Click to expand...
Click to expand...
 
I went to MSDN feedback with the intention to add my suggestion but I
did the mandatory search I found the following suggestion (FDBK19141)
that pretty much mirrors mine. It was made over a year ago, and much
to my surprise, it was simply dismissed as not significant enough by
Microsoft. I find this rather ignorant, as this could greatly improve
the robustness of the code we all create. I will try to vote for this
suggestions even though it's closed. I will also post a new suggestion
and hope for a different outcome. I'll let you all know when it's in
and what it's number is.

Andrew
 
Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.

Thanks.

Andrew
 
I voted in favour, although I prefer that nameof() return the simple
property / method / class name as a string. This would make the feature
free at runtime: the compiler simply substitutes a string for the
nameof(...). You can always get Reflection info if you want it:

myObject.GetType().GetProperty(nameof(myObject.PropertyName))

for example. However, if you're doing binding, where you don't need
Reflection info at all, you get more maintainable code for no runtime
penalty at all.
 
I voted in favour, although I prefer that nameof() return the simple
property / method / class name as a string.
Click to expand...

I agree, and I see some problems with the infoof Nick suggested that a
simple nameof wouldn't have.

First, I would expect it to work on all identifiers in the C# code
even if the name gets lost in the compilation process. The prime
example is local variables that don't have their names in metadata,
only in the debug symbols (and hence LocalVariableInfo doesn't have a
Name property).

Second, if the operator returns a MethodInfo for methods you would
somehow have to specify which overload you wanted if there's more than
one. And I would hate it if I had to write something like
infoof(MyMethod(int, string, bool)).Name just to get the string
"MyMethod".


Mattias
 
Here is the feedback ID for the one I just submitted: FDBK43926. I
found some other items that are somewhat related as well. If you like
this idea maybe you could drop in a vote.
Click to expand...

They have resolved it as duplicate, but the duplicate has nothing to do
with infoof/nameof. This feature is really important! I actually don't
use data binding and stay away from reflection wherever possible because
of that. I don't get why they still don't have anything like that even
in the C# 3.0 specs!

I'll have the whole team vote for this.. but what feedback ID should we
agree to vote on? Yours has been resolved, so voting on it is not
possible anymore!

Max
 
Here is what I propose.

There are currently three feedback suggestions that pertain to this problem.
One is the original post that request exactly the nameof() operator in a
clear and succint way (FDBK19141). There is the one that TAG refers to as
the duplicate of mine, but which is quite convoluted and starts of talking
about default values of attributes (FDBK20362). And finally, there is my
new post (FDBK43926).

I believe we can vote even on closed suggestions, but I did notice that once
they changed the status of my suggestion all the previous votes disappeared.
I suggest we drop our votes on all three of these suggestions, and also post
comments to all of them indicating clearly what it is that we want.
Comments seem to always be open and persist even if the status is closed or
otherwise changes.

My feeling is that Microsoft is evaluating a very broad (and complex) scheme
of providing any reflection information via some form of operator (or
operators) which may prove difficult to implement or use. I think they
should focus it more narrowly first, while giving the broader scope some
consideration. But I would hate to see the nameof() be dropped because the
all-reflection-info-of() proved to be to difficult to do.

Help me out.

Thanks,

Andrew
 
If you try and vote on your new entry, you are automatically redirected to
FDBK22652 which is now showing as re-opened.

I for one have voted with a 5 as I think this would be a major enhancement
for any developer.
 
Jedrzej said:
Here is what I propose.

There are currently three feedback suggestions that pertain to this problem.
One is the original post that request exactly the nameof() operator in a
clear and succint way (FDBK19141). There is the one that TAG refers to as
the duplicate of mine, but which is quite convoluted and starts of talking
about default values of attributes (FDBK20362). And finally, there is my
new post (FDBK43926).

I believe we can vote even on closed suggestions, but I did notice that once
they changed the status of my suggestion all the previous votes disappeared.
I suggest we drop our votes on all three of these suggestions, and also post
comments to all of them indicating clearly what it is that we want.
Comments seem to always be open and persist even if the status is closed or
otherwise changes.
Click to expand...

I left a comment on FDBK22652 (yours is listed a duplicate of that) and
voted for both FDBK22652 and FDBK19141 with a 5. I know my colleagues
also want something like nameof() since a long time too, I'll get their
votes on monday.

Max
 
FDBK43926 has been re-opened!

I have voted for this also (with a 5)

I suggest everybody else votes as well in order to get this on the list.
 
Nicholas Paldino said:
Also, I wouldn't go with a nameof operator though, I would go with
something like infoof (read "in-foof", ha).
Click to expand...

Calling it nameof() wouldn't be without precedent however, eg
System.Reflection.AssemblyName has a lot more than an assembly's name.

infoof() seems a little "foofy" to me... :-)

-- Alan
 
Back
Top