Introduction
In some way, the article is a continuation the previous one entitled “What if names would contain white spaces?”. It's a part of series of articles devoted to the latest C# and Java programming language features.
In this article I would like to discuss about “nameof” operator supported by C# 6. It allows to map strings to named code elements. It's really useful feature within your code for some reasons. In order to understand the main areas of its application, let's consider following examples.
Example 1: Exceptions Handling
The main reason to add “nameof” is exceptions handling. When throwing an “ArgumentException” and its derivatives, you'd use a string for the name of the corresponding parameter that was invalid. Unfortunately, these strings had no compile time validation and any code changes (such as renaming classes, methods, properties, fields and variables) wouldn't automatically update the string, resulting in an inconsistency that was never caught by the compiler.
void SomeMethod<T>(T value) {
if (value == null)
throw new ArgumentNullException(paramName: nameof(value));
if (!(typeof(T) is Iinterface))
throw new ArgumentException (nameof(T),
$"Type '{typeof(T)}' does not support the method" +
$"' { nameof(MyNamespace.MyClass)}.{nameof(SomeMethod)}'." );
}
It's also possible to write the following code, although the method isn't static:
$"Type '{typeof(T)}' does not support the method "+
$"'{nameof(MyNamespace.MyClass.SomeMethod)}'."
I want to write “MyNamespace.MyClass.SomeMethod” in “nameof” literally, but the compiler cut my string to “SomeMethod”. So the operator name completely satisfies to the expected behavior. It should be kept in mind when writing code.
Example 2: Notifiable Properties
The other reason widely presented in publications about new features of C# 6 is improving code of “OnPropertyChanging” and “OnPropertyChanged” event raising of “INotifyPropertyChanging” and “INotifyPropertyChanged” interfaces, respectively. The interfaces notify clients that a property value is changing or has already changed.
public class SomeClass : INotifyPropertyChanging, INotifyPropertyChanged {
public event PropertyChangingEventHandler PropertyChanging;
protected virtual void OnPropertyChanging(String propertyName) {
var handler = PropertyChanging;
if (handler != null) handler(this, new PropertyChangingEventArgs(propertyName));}
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(String propertyName) {
var handler = PropertyChanged;
if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));}
public const String DEFAULT_SOME_TEXT = "Default value";
private String _someText = DEFAULT_SOME_TEXT;
[DefaultValue(DEFAULT_SOME_TEXT)]
public String SomeText {
get { return this._someText; }
set {
if ( String.Equals( this._someText, value ,
StringComparison.CurrentCultureIgnoreCase))
return;
OnPropertyChanging("SomeText");
OnPropertyChanging(this.NameOf( o => SomeText ));
OnPropertyChanging(nameof(SomeText));
this ._someText = value ;
OnPropertyChanged("SomeText");
OnPropertyChanged(this.NameOf( o => SomeText ));
OnPropertyChanged(nameof(SomeText));
}
}
}
The code is a very good example of how useful the new possibilities of C# 6 are. Almost every developer wrote similar code and knows how difficult is to keep in mind properly names of the properties described as a string. However, it isn't necessary to write the name of the caller property when the “System.Runtime.CompilerServices.CallerMemberNameAttribute” attribute appeared in .NET 4.5. This attribute enables to decorate method arguments, indicating that the appropriate piece of information is injected into that argument when the method is called.
protected virtual void OnPropertyChanging(
[CallerMemberName] String propertyName = "") { ... }
protected virtual void OnPropertyChanged(
[CallerMemberName] String propertyName = "") { ... }
...
OnPropertyChanging();
this._someInt = value;
OnPropertyChanged();
These classes are very popular in a wide range of projects. For example, the WPF makes it possible to use the “INotifyPropertyChanged” interface. If the object in the “DataContext” property implements this interface, WPF will listen for its “PropertyChanged” event. This event signals changes to property values. When the event is raised, it indicates a change to a UI control binding and the displaying value changes accordingly. So there are more compact solutions.
[Serializable]
public class SomeClass : INotifyPropertyChanging, INotyfyPropertyChanged {
#pragma warning disable 0067 // The event raised by PropertyExt extensions
[field: NonSerialized]
public event PropertyChangingEventHandler PropertyChanging;
[field: NonSerialized]
public event PropertyChangedEventHandler PropertyChanged;
#pragma warning restore 0067
public const String DEFAULT_SOME_TEXT = "Default value";
private String _someText = DEFAULT_SOME_TEXT;
[DefaultValue(DEFAULT_SOME_TEXT)]
public String SomeText {
get { return this._someText; }
set { this.SetPropertyAndNotify(ref _someText, value); }
}
public const Int32 DEFAULT_SOME_INT = 123;
private Int32 _someInt = DEFAULT_SOME_INT;
[DefaultValue(DEFAULT_SOME_INT)]
public Int32 SomeInt {
get { return this._someInt; }
set { this.SetPropertyAndNotify(ref _someInt, value); }
}
}
The extension method “SetPropertyAndNotify” may have the following implementation:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Reflection;
using System.Runtime.CompilerServices;
public static class PropertyExt {
public static void SetPropertyAndNotify<t>(
this INotifyPropertyChanged source,
ref T field,
T value,
[CallerMemberName] String propertyName = "",
EqualityComparer<t> equalityComparer = null)
{
if (source == null)
throw new ArgumentNullException("source");
if (!(equalityComparer ?? EqualityComparer<t>.Default).Equals(field, value)) {
if (source is INotifyPropertyChanging) {
RaiseEvent(source, "PropertyChanging",
new PropertyChangingEventArgs(propertyName));
}
field = value;
RaiseEvent(source, "PropertyChanged",
new PropertyChangedEventArgs(propertyName));
}
}
private static void RaiseEvent<teventargs>(
this Object source,
String eventName,
TEventArgs eventArgs)
where TEventArgs : EventArgs
{
var eventDelegate = (MulticastDelegate)source.GetType()
.GetField(eventName, BindingFlags.Instance | BindingFlags.NonPublic)
.GetValue(source);
var parameters = new Object[] { source, eventArgs };
foreach (var handler in eventDelegate.GetInvocationList()) {
handler.Method.Invoke(handler.Target, parameters);
}
}}</teventargs>
As mentioned earlier, there are many good solutions where there is no need to use the operator “nameof”: “MVVM Light” (“NuGet PM: Install-Package MvvmLight”), “AOP PostSharp” (“NuGet PM: Install-Package PostSharp”; see also “AOP Implementation of INotifyPropertyChanged”), “Kind of Magic” (CodePlex, VS Gallery). Furthermore, in certain cases, the operator may become the reason of writing of a low-quality code.
For compatibility with legacy code, it can avoid the “nameof” operator via helper methods based on tree expressions.
using System;
using System.Linq.Expressions;
namespace Example {
public static class NameOfExt {
public static String NameOf(Expression<action> accessor) {
return InternalNameOf(accessor); }
public static String NameOf<t>(Expression<func<t>> accessor) {
return InternalNameOf(accessor); }
public static String NameOf<t, u="">(this T obj, Expression<func<t, u="">> accessor) {
return InternalNameOf(accessor); }
private static String InternalNameOf(Expression expression) {
if (expression == null )
throw new ArgumentNullException ( "expression" );
if (expression is LambdaExpression )
return _NameOf((( LambdaExpression ) expression).Body);
if (expression is UnaryExpression )
return NameOf((( UnaryExpression ) expression).Operand);
var memberExpression = expression as MemberExpression ;
if (memberExpression != null )
return memberExpression.Member.Name;
MethodCallExpression methodExpression = expression as MethodCallExpression ;
if (methodExpression != null )
return methodExpression.Method.Name;
throw new ArgumentException (
"The 'expression' should be a member expression or a method call expression." ,
"expression" );
}
}
internal class Program {
internal static void Main(string[] args) {
var str = "Some String";
Console .WriteLine(str.NameOf(o => o.Length));
Console .WriteLine(str.NameOf(o => o.GetType()));
Console .WriteLine( NameOfExt .NameOf(() => String .Empty));
Console.WriteLine(NameOfExt.NameOf(() => String.Copy("")));
}}} </func<t,>
Similar code was written before the appearance of “nameof” operator. But “nameof” becomes a string constant during compilation instead of execute code to obtain name of code element by using tree expressions or reflection methods. So the introduced operator is a big advantage of C#, but it's also a disadvantage too. The possibilities of JIT-compiler isn't involved. It doesn't allow to predict the dynamic code changes and to substitute the name rightly. Besides, there is no opportunity to transform part of a code to string by principle “as is” to track its further changes: “System.Math.PI”, “Type Property” or “Type Namespace.Class.Method(Type arg0, Type arg1, ...)”. Functional style of the operator is perhaps doubtful. I'd want to ask a question: what type of argument? But the question disappears, because already there are similar methods like “typeof”. In addition, after compilation the method-like operator is replaced by string. Perhaps, it would be more natural to expand functionality of the string interpolation for strict and literally transform parts of code to string with validating it at compile time:
$"'\@{MyNamespace.SomType}', '\@{SomType arg0}', '\@{arr[index]}'."
$"'\@{MyNamespace.{SomeType}}', '\@{{SomType} arg0}', '\@{{public }int {Prop}}'."
The probability of that the “nameof” operator will be a part of interpolated string is very high. The offered syntax of refactorable strings may be applied conveniently in the comments:
In case of the self-documented comments similar functionality is partially available:
Double Method(Double x, Double y) { ... }
void SomeMethod<T>(T value) {
if (value == null )
... }
Let's show real practical usage of “nameof” in object notifications at last. You may ask a question based on the foregoing examples. Where can it be useful, when a good implementation of “INotifyPropertyChanged” interface doesn’t contain it? It's necessary to remember that the “PropertyChanged” event has subscribers. The expected action can't be performed, if the property name is defined incorrectly.
private static void NPCSubscriber_PropertyChanged(
Object sender,
PropertyChangedEventArgs e)
{
switch (e.PropertyName) {
case nameof(ISomeClass.SomeInt): ... break;
case nameof(ISomeClass.SomeText): ... break;
default:
throw new InvalidOperationException();
}
}
It should be kept in mind when the “NPC” class (contained “Notify Property Changed” event) designing, the operator “nameof” defined in a subscriber can't access to hidden members:
class ClassWithHiddenMembers {
protected Int32 Protected { get { return _protected; } }
protected Int32 _protected;
}
class ClassForTestingOfPrivateMembersAccess {
public override string ToString()
=> $"{nameof(ClassWithHiddenMembers._protected)}, "
+ $"{nameof(ClassWithHiddenMembers.Protected)}";
}
The example of “PropertyChanged” subscriber implementation is very revealing. The properties which notify changes are grouped in the separate interface. It can improve readability and in some cases, the hidden members can be implemented explicitly:
internal interface IClassWithHiddenMembers {
Int32 Protected { get; }
}
class ClassWithHiddenMembers : IClassWithHiddenMembers {
protected Int32 Protected { get { return _protected; } }
Int32 IClassWithHiddenMembers.Protected {
get { return _protected; }
}
protected Int32 _protected;
}
The example of “PropertyChanged” subscriber implementation has another weakness. The compared properties in “switch” operator are presented as strings that pass very poor information about it. If there is a lot of string names for comparison, the “switch”-design becomes ineffective and reduces the performance slightly. It would be desirable to compare references instead of strings. So, sometimes there is a wish to write following code:
[Serializable]
public class NPC : INotifyPropertyChanged {
#region "INotifyPropertyChanged" interface implementation
[field:NonSerialized]
public event PropertyChangedEventHandler PropertyChanged;
protected void OnPropertyChanged([CallerMemberName] String propertyName = "") {
OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
}
protected virtual void OnPropertyChanged(PropertyChangedEventArgs evt) {
if (evt == null) return;
var handler = PropertyChanged;
if (handler != null) handler(this, evt);
}
#endregion "INotifyPropertyChanged" interface implementation
public const String DEFAULT_SOME_TEXT = "Default value";
public static readonly PropertyChangedEventArgs CHANGED_SOME_TEXT_EVENT_ARGS
= new PropertyChangedEventArgs(nameof(SomeText));
private String _someText = DEFAULT_SOME_TEXT;
[DefaultValue(DEFAULT_SOME_TEXT)]
public String SomeText {
get { return this._someText; }
set {
if (String.Equals(this._someText, value,
StringComparison.CurrentCultureIgnoreCase))
return;
this._someText = value;
OnPropertyChanged(CHANGED_SOME_TEXT_EVENT_ARGS);
}
}
...
public static void Npc_SomeTextPropertyChanged(
Object sender, PropertyChangedEventArgs e) {
if (e == NPC.CHANGED_SOME_TEXT_EVENT_ARGS) {
}}
Surprisingly, the “PropertyChangedEventArgs” class and others classes inherited from “EventArgs” aren't overloaded “Equals” methods. It would have to look like following code:
public class PropertyChangedEventArgsEx: EventArgs {
public PropertyChangedEventArgsEx(string propertyName) {
this.PropertyName = propertyName; }
public virtual string PropertyName { get; private set; }
public override Boolean Equals(Object obj) {
return Object.ReferenceEquals(this, obj)
|| ((obj is PropertyChangedEventArgsEx)
&& String.Equals(PropertyName, ((PropertyChangedEventArgsEx)obj).PropertyName))
|| base.Equals(obj);
}
}
Why so often not to implement the “Equals” method? Maybe the answer would be simple. It's very difficult to keep that in mind, especially if you don't know how the class will be used. In addition, the methods “GetHashCode” and “ToString” are required to implement too, because the warning “CS0659” appeared. So there is a wish to take advantage of AOP.
[Equals]
public class PropertyChangedEventArgsEx: EventArgs {
public PropertyChangedEventArgsEx(String propertyName)
{ this.PropertyName = propertyName; }
public virtual String PropertyName { get; private set; }
}
For example, there is an extensible tool “Fody” for weaving .NET assemblies. It has the good “Equals” generator “Fody/Equals” (“NuGet PM: Install-Package Equals.Fody”). It generate “Equals”, “GetHashCode” and operators methods from properties for class decorated with a “[Equals]” attribute. Also the tool “Fody/PropertyChanged” (“NuGet PM: Install-Package PropertyChanged.Fody”) provides an easy way to inject “INotifyPropertyChanged” code into properties at compile time.
Example 3: Reflection
Reflection are used for obtaining metadata of assembly and type structure at runtime. The classes that give access to the metadata of a running program are in the “System.Reflection” namespace. Also the reflection allows creating new code at runtime and then performs it dynamically. Quite large number of articles is devoted to it, for example: “Reflection in .NET”, “Reflection optimization techniques”, “Reflection with Example”, “Dynamic Type Using Reflection.Emit”, “HyperDescriptor: Accelerated dynamic property access”, “ExpressionToCode, Passert”, “Creating static methods at runtime”, “Reflection is Slow or Fast? A Practical Demo” and etc.
There can be an impression that the dynamic programming improvements was suspended after the addition of “dynamic” keyword. But this is not true. The next “dynamic” step could give the “nameof” operator. A lot of sources containing a reflection methods have a string names of finding or creating members. In such cases it's very convenient to use “nameof” operator. Let's look back to the example of “NPC” code. Properties could have values by default described by “System.ComponentModel.DefaultValueAttribute”. The value of attribute can be only obtained by reflection.
[DefaultValue(DEFAULT_SOME_TEXT)]
public String SomeText {
get { return this._someText; }
set {
if (String.IsNullOrEmpty(value)) {
value = GetType()
.GetProperty(nameof(SomeText))
.GetCustomAttribute<defaultvalueattribute>().Value as String;
}
if (String.Equals(this._someText, value,
StringComparison.CurrentCultureIgnoreCase))
return;
this._someText = value;
OnPropertyChanged();
}}</defaultvalueattribute>
The example above demonstrates how the “nameof” operator is useful in reflection. However, it shows the weakness of reflection. It's necessary to perform too much low-productive operations to obtain required attribute. The code scope is known at compile time, but it needs to obtain it “dynamically” by processing of countless string arguments and list enumerations. But the getting attribute information is the most popular action of reflection. It should be simple and more efficient.
After looking at “PropertyChangedEventArgs” class in “PropertyChanged” event again, appears a clear understanding that, perhaps, “PropertyName” should be named “Property” with type “System.Reflection.PropertyInfo”. This type has the correctly implemented methods “Equals” and “ToStrinsg” and has a sufficient information to make a decision how it should compare and convert to string. However, the classes located in “System.Reflection” namespace aren't advisable to use for some reasons. It seems that the dynamics is slow and it breaks down the object oriented principles. Therefore it should be kept separately and be used only in rare cases. But in real projects, the situation around the reflection in C# is similar of the “#define” preproccessor directive being used in C++: “C Preprocessor tricks, tips, and idioms” or “What are some tricks I can use with macros?”. It's required to use it only where impossible avoid it. However, in real projects, the directive is applied everywhere. Today, there is a wide gap between native programming and meta-programming (reflecting, DLR) in C#. Perhaps, the gap needs to be reduced. Let's imagine how it might be done.
A lot of arguments of reflected elements passed to its methods have string type. Performing string conversions and dynamic binding requires considerable time. However, it's often necessary to refer to an existing code element placed in the current or public context (scope) or to reflect it. If this is taken into account, it's possible to significantly improve the performance. Let's consider the following code.
namespace ReflectionPatterns {
public reflecting field pattern _field1; public reflecting field pattern Int32 _field2;
[RequireAttribute(typeof(SerializableAttribute))]
public reflecting field pattern Int32 _field3;
[TypeCast][AnyName][Static][MemberScope(Scope.Private | Scope.Internal)]
public reflecting field pattern Object PrivateOrInternalFieldWithAnyName;
[TypeCast][RegularExpression(@"^_field\d+$")]
public reflecting field pattern Object FieldWithRegExprName;
public reflecting property pattern Property1; public reflecting property pattern Int32 Property2 {get;} public reflecting property pattern Int32 Property3 {set;} [TypeCast][AnyName][field:RequireAttribute(typeof(SerializableAttribute))]
public reflecting property pattern Int32 PropertyWithAnyName {get; set;}
[RegularExpression(@"^Property\d+$")]
public reflecting property pattern PropertyWithRegExprName;
public reflecting event pattern Event1; public reflecting event pattern EventHandler Event2;
[TypeCast][AnyName][MemberScope(Scope.Public | Scope.Protected)]
public reflecting event pattern EventHandler PublicOrProtectedEventWithAnyName;
[TypeCast][RegularExpression(@"^.*?Event(?:\d+)?$")]
public reflecting event pattern EventWithRegExprName;
public reflecting method pattern Method; public reflecting method pattern Int32 Method1; [return:RequireAttribute(typeof(OutAttribute))]
public reflecting method pattern Int32 Method2<t> where T:struct;
[DynamicType("MethodType")][DynamicName("MethodName")]
public reflecting method pattern Int32 MethodWithDynamicParts(
[RegularExpression(@"^arg\d*$")] [DynamicName("ArgumentName")] T arg);
[RegularExpression(@"^.*?Class(?:\d+)?$")]
[BaseClassName(@"^Base.*?Class$")][InterfaceName(@"^I.*?Connection$")]
[NestedPatern(Class1, Method1, Property1)][RequiredMembers(typeof(IInterface))]
public reflecting class pattern ClassRegExprName : IInterface1, Iinterface2;
}</t>
The reflecting pattern definition could be written and placed just like delegates. The patterns describe intuitively clear rules to find classes and its members statically and dynamically. The rules are a kind of dynamic language like “LINQ”. It adds native meta-information querying capabilities by the reflecting patterns and the set of extension methods. The patterns allows developers to understand visually that it is required to find. It also allows to check the syntax and to simplify searching queries during the compilation. In many cases the results of reflection can be given at the compile time. Getting the information corresponding to the reflecting pattern is performed by “reflect<T>(target)” operator. The template parameter “T” is reflection pattern or type being attribute or nesting to assembly or another type. The argument “target” is class instance, type or string.
var fieldInfo1 = reflect<_field1>(this); var fieldInfos = reflect<PrivateOrInternalFieldWithAnyName[]>(typeof(SomeType));
var fieldInfo01 = reflect<_field1>(); class SomeType {
public FieldInfo InstanceGetFieldInfo() {
var fieldInfo = reflect<_field1>();
return fieldInfo;
}
public static FieldInfo StaticGetFieldInfo() {
var fieldInfo = reflect<_field1>();
return fieldInfo;
}
This approach can significantly simplify the way of interaction with the attributes.
[DefaultValue(DEFAULT_SOME_TEXT)]
public String SomeText {
get { return this._someText; }
set {
if (String.IsNullOrEmpty(value)) {
value = reflect<DefaultValueAttribute>()?.Value as String;
}
if (String.Equals(this._someText, value,
StringComparison.CurrentCultureIgnoreCase))
return;
this._someText = value;
OnPropertyChanged();
}}
The compiler can simplify the code presented above in the best way. Let's look at other examples.
MethodInfo[] mi = reflect<MethodPattern[], ClassPattern>();
MethodInfo[] mi = reflect<MethodPattern[], ClassPattern>(
"MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7779fa1be111eb0c");
FieldInfo<FieldPattern> fieldInfo = reflect<FieldPattern>();
MethodInfo<MethodPattern> methodInfo = reflect<MethodPattern>();
MethodInfo<PropertyPattern> propertyInfo = reflect<PropertyPattern>();
OldValue = propertyInfo.GetValue(this); propertyInfo.SetValue(this, NewValue);
methodInfo.Invoke(this, arg0, arg1, ..., argN);
MethodInfo<MethodWithDynamicParts> methodInfo = reflect<MethodWithDynamicParts>(
"Namespace.Class", new {MethodType = typeof(Int32), ArgumentName="argument0"});
);
The example of getting and setting property values and calling the method by reflection shows that a further feature is required. It is “typed references”.
The typed reference defined by “reference<T>(target)” operator. It's like “reflect” operator. The operator allows to make a link with property, event, method or field. Its implementation should be lightweight and be similar “references” in C++. Its performance should be close to the direct calling the part of code referred by one. The behavior of references should be similar to the members to which they refer. The assignment and equality of references could be defined as additional operations. In this case, the performance of NPC subscribers may be improved significantly by comparing the typed references instead of strings.
namespace ReflectedTypes {
[AnyName]
public reflecting property pattern PropertyPattern {get;}
public reference PropertyRef : PropertyPattern;
class NPC : INotifyPropertyChanged {
...
public Int32 Property {
get { return _property; }
set {
if (_property == value) return;
_property = property;
PropertyChanged(reference<PropertyRef>(this));
}
}
private Int32 _property;
}
class Program {
static void NPCSubscriber(Object sender, PropertyChangedEventArgs e) {
PropertyRef propRef = e.Property as PropertyRef;
if (propRef != null && propRef is reference(NPC.Property)) {
Console.WriteLine("Type: {0}, name: {0}, value: {1}",
propRef.Container.GetType(), propRef, propRef.Reference);
}
}
static void Main(string[] args) {
var obj = new NPC();
obj.PropertyChanged += NPCSubscriber;
}
}}
It may seem that the references are not necessary due to already existing delegates. However, their heavy functional possibilities shouldn't be required in many cases excepting events. All features of delegate (see source code of “Delegate” and “MulticastDelegate” classes) can be written transparently by typed references in ordinal classes without any hacks:
public abstract class Delegate : ICloneable, Iserializable {
[System.Security.SecurityCritical]
internal Object _target;
[System.Security.SecurityCritical]
internal Object _methodBase;
[System.Security.SecurityCritical]
internal IntPtr _methodPtr;
[System.Security.SecurityCritical]
internal IntPtr _methodPtrAux;
[System.Security.SecuritySafeCritical] protected Delegate(Object target, String method) {
if (target == null)
throw new ArgumentNullException("target");
if (method == null)
throw new ArgumentNullException("method");
Contract.EndContractBlock();
if (!BindToMethodName(target, (RuntimeType)target.GetType(), method,
DelegateBindingFlags.InstanceMethodOnly |
DelegateBindingFlags.ClosedDelegateOnly))
throw new ArgumentException(Environment.GetResourceString("Arg_DlgtTargMeth"));
}
...
[System.Security.SecurityCritical] [ResourceExposure(ResourceScope.None)]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
private extern bool BindToMethodName(Object target,
RuntimeType methodType, String method, DelegateBindingFlags flags);
...
[System.Security.SecuritySafeCritical] protected virtual object DynamicInvokeImpl(object[] args) {
RuntimeMethodHandleInternal method =
new RuntimeMethodHandleInternal(GetInvokeMethod());
RuntimeMethodInfo invoke =
RuntimeType.GetMethodBase((RuntimeType)this.GetType(), method);
return invoke.UnsafeInvoke(this, BindingFlags.Default, null, args, null);
}
...
[System.Security.SecuritySafeCritical] protected virtual MethodInfo GetMethodImpl() {
if ((_methodBase == null) || !(_methodBase is MethodInfo)) {
IRuntimeMethodInfo method = FindMethodHandle();
RuntimeType declaringType = RuntimeMethodHandle.GetDeclaringType(method);
if(RuntimeTypeHandle.IsGenericTypeDefinition(declaringType)
|| RuntimeTypeHandle.HasInstantiation(declaringType)) {
bool isStatic = (RuntimeMethodHandle.GetAttributes(method)
& MethodAttributes.Static) != (MethodAttributes)0;
if (!isStatic) {
if (_methodPtrAux == (IntPtr)0) {
Type currentType = _target.GetType();
Type targetType = declaringType.GetGenericTypeDefinition();
while (currentType != null) {
if (currentType.IsGenericType
&& currentType.GetGenericTypeDefinition() == targetType) {
declaringType = currentType as RuntimeType;
break;
}
currentType = currentType.BaseType;
}
BCLDebug.Assert(currentType != null || _target.GetType().IsCOMObject,
"The class hierarchy should declare the method");
} else {
MethodInfo invoke = this.GetType().GetMethod("Invoke");
declaringType = (RuntimeType)invoke.GetParameters()[0].ParameterType;
}
}
}
_methodBase = (MethodInfo)RuntimeType.GetMethodBase(declaringType, method);
}
return (MethodInfo)_methodBase;
}
...
}
By studying the code, it can be concluded that without the references it is not possible to write good-quality code. That is why the developers of C# create it by small hack (see “_methodPtr” or “_methodPtrAux” fields having internal accessibility). If there are no references, it have to use the slow reflection. There is a similar situation with classes placed in “System.Reflection” and “System.Dynamic” namespaces. So maybe it should append the typed references explicitly without any hacks?
The “reflect” and “reference” operators would be recommended to use for reflection. Maybe it's better approach compared with existing one. In most cases “.NET” would perform a pretty good optimization, because it's possible to predict what kind of information is needed at compile time. The various code could be created by compiler depending on the situation. Also it should be noted that the reflection becomes friendly to the developers by using ones.
Conclusion
I believe “nameof” operator provided new good opportunities to be entirely worthy of the attention. It will save us countless hours of fixing mistaken refactoring, arguing over coding style and code reviews, and head-scratching at implicit errors. On the other hand, it reveals some of the language issues, which should be properly investigated and made some improvements in C#. There are other very interesting issues that will be discussed in future articles.
I would greatly appreciate the opinion of readers who express their point of view and answer the question. Do you have any good practical examples of reflections (“System.Reflection”, “System.Reflection.Emit”, “System.Dynamic”, “Expression trees”, “dynamic”, and etc) used in real projects? It would be nice, if it would be possible to use the “nameof” operator in your examples.
Points of Interest
It's wonderful to find and learn the good software engineering principles, nice approaches in source code and modern frameworks allow us to write really flexible code.
History
09/02/2016 - First version
