The system and methods for providing type safe member metadata access in programming languages with reflection support are further described with reference to the accompanying drawings in which:
Reflection is a powerful mechanism provided by some major object oriented languages and frameworks that allows to access information about classes and their members at metadata level, and use it in different scenarios. Some of few use cases are: detecting what kind of methods or fields does the class have, detecting the specific field data type at runtime, dynamically invoking method which name is unknown at compile time. These are non-standard cases of classical object oriented programming, but they make a great significance in contemporary object oriented design solutions and frameworks where modularity and extensibility are key values (1).
Reflection is designed the way that metadata access is not straightforward and type-safe for distinct members. The usual scenarios of using reflection allow:
Previously demonstrated examples show existing technique of accessing metadata in two major general purpose programming languages: C# and Java. Providing type member name as string instances to access type member metadata are not type safe. It means that code is not reliable for maintenance (refactoring) and also if there is a mistake it will be noticed only at runtime.
The most obvious benefit of static type-checking is that it allows early detection of some programming errors. Errors that are detected early can be fixed immediately, rather than lurking in the code to be discovered much later, when the programmer is in the middle of something else or even after the program has been deployed. Most of general purpose object-oriented programming languages are strongly typed, but none of them provide fully type safe metadata access mechanism—they lack type safe type (class/structure) member metadata access. Not all programming languages support metadata access mechanisms like reflection, but for languages which support metadata access, type safety in this field is considered to be a property of a computer program rather than the language in which that program is written. In such cases programmer is responsible for type safety which means correct metadata representation in basic data types, usually strings.
In C#5, it is possible to tag optional parameters with one of three caller info attributes (9), (10): [CallerMemberName] applies the caller's member name; [CallerFilePath] applies the path to caller's source code file; [CallerLineNumber] applies the line number in caller's source code file. By using CallerInfo attributes, it is possible to obtain information about the caller to a method. You can obtain file path of the source code, the line number in the source code, and the member name of the caller. CallerInfo attributes instruct the compiler to feed information obtained from the caller's source code into the parameter's default value: This information is helpful for tracing, debugging, and creating diagnostic tools.
All mentioned downsides can be solved by introducing language improvements to support type safe metadata access which would make compile-time checks possible. Type metadata gathering operator “typeof” (C#) and “.class” call (Java) returns metadata about specified type (class, structure, interface), but there is no type safe way to access class member metadata. For example, programming languages can be extended with operator named ‘memberof’ so that memberof(classField) returns field metadata instance FieldInfo (C#) or Field (Java) instances instead of field value instances. Microsoft® has been working on design of type safe member metadata access operator named “infoof” (11). The following example shows how non-static field from previous example can be accessed without using instance reference of class:
Field ‘FullName’ is used like static field, but since type cannot have instance level member and static level member with the same name, there should be no misunderstanding to which field we are pointing to and system should return correct metadata instance. The same is with methods, properties, events and constructors.
Microsoft® has been thinking about operator infoof as similar operator to operator typeof which allows type safe metadata access:
Type info=typeof (int);
Operator typeof accepts parameter which is type instead of instance. Following example is invalid according to C# specification:
Type x=typeof(6);
Use cases of member metadata access operator, that does not accept instance expressions as operator parameter, are too specific and that is not enough for fully type safe member metadata access.
Current invention provides methods for type safe type (class/structure) member metadata access in programming languages with support reflection. Type member metadata access invention is based on introduction of different forms of generic forms of operator ‘memberof’, context dependent operator ‘member’ and method parameter modifier ‘meta’ which forces compiler to interpret method actual parameter as metadata access expression instead of value access expression. Introduced operators require changes in programming frameworks like .NET, Java and others, as well as propose improvements in syntax of general purpose programming languages, but as result make programming languages fully type safe in metadata access field.
The disclosed invention facilitates extending object oriented programming languages with new operators to support type safe type (class/structure) member metadata access.
Member metadata access operator can be designed to work also with member instance expressions as demonstrates
In .NET class MemberInfo is base class for classes: FieldInfo, MethodInfo, PropertyInfo, ConstructorInfo, EventInfo and in cases when is needed only type safe member name determination, better is to use MemberInfo instance. Similar metadata type system architecture is in programming language Java, differs only metadata class names and usage syntax:
C# examples using operator memberof are demonstrated in
One of most valuable use cases of operator ‘memberof’ could be in design pattern MVVM ViewModel declarations.
Many programming languages have operator ‘this’ which points to current instance context, but none of programming languages have operator which could point to current instance member context. Such operator could be operator named ‘member’ as shown in
Sometimes it's required not only to access type member metadata, but also to process type member taking into consideration some parameter(s) whose type should be compatible with initial member type. For example, in database querying useful could be method ‘FilterByEquality’ declared as shown in
Now operator ‘memberof’ should return generic versions of metadata instances.
memberof(suppliedField) which should return FieldInfo<T> instance and T is type of field ‘supplied Field’;
memberof(suppliedMethod(parameter type list—optional)) which should return MethodInfo<T> instance and type T is type container for all ‘suppliedMethod’ parameters. In .NET this type container could be standard delegate: Func< . . . > or Action< . . . >. Which type exactly will function as type container depends on ‘suppliedMethod’ returning type—for methods with returning value type container will be Func< . . . > and for methods without returning value (void) type container will be Action< . . . >. It is possible to use custom type container types, but better is to stick to well-known standard classes, this way it would be possible to use implicit type declarations (keyword ‘var’);
memberof(suppliedProperty) which should return PropertyInfo<T> instance and T is type of property ‘suppliedProperty’;
memberof(suppliedClass(parameter type list—optional)) which should return ConstructorInfo<T> instance and type T is type container for all ‘suppliedClass’ constructor parameters. In .NET this type container could be standard delegate Action< . . . >;
memberof(event) which should return EventInfo<T> instance where type T should specify event argument (in should be class EventArgs or class which inherits from EventArgs);
Similarly improved operator ‘memberof’ can be designed for Java and other programming languages. Usage examples of improved operator ‘memberof’ are demonstrated in
In programming languages which does not support delegates, programmer needs to take care of designing type containers for method parameters. Type ‘Action’ variations are supposed to function as method parameter type containers for methods which do not have returning value (void methods). Type ‘Action’ is supposed to describe fact that method does not have parameters; Action1<T1> is supposed to describe fact that method has one parameter with type should equal to generic parameter T1; Action2<T1, T2> is supposed to describe fact that method has two parameters which types should be equal to generic parameters T1 and T2 accordingly; and so on . . . .
Similarly is with ‘Func’ variations. ‘Func’ acts as method parameter type container for methods which return value. Func<R> is supposed to describe fact that method does not have parameters and type of returning value should be equal to generic parameter R. Func1<T1, R> is supposed to describe fact that method has one parameter of type which should be equal to generic parameter T1 and type of returning value should be equal to generic parameter R. Func2<T1, T2, R> is supposed to describe fact that method has two parameters of types which should be equal to generic parameters T1 and T2 accordingly and type of returning value should be equal to generic parameter R.
Please note that the final names of ‘Action’ and ‘Func’ type containers can be changed depending on a target framework. E.g., C# already provides such types along with delegates, and it allows using the same name across different versions (different generic parameters' count designates different types). However, in case of Java generics are processed differently, and different type names required even if generics declaration differs. The Action, Action1, Action2, . . . and Func, Func1, Func2, . . . could be introduced in Java as a metadata parameter holders.
Taking into consideration all previously proposed ideas, method ‘FilterByEquality’ example can be improved as shown in
Important part is in expression: memberof(Person.FullName) which returns FieldInfo<T> instance where type T is determined as string. Compiller automatically detects type of variable ‘memberMetadata’ from ‘memberof’ operator call context and in example this type is MemberInfo<string>. Demonstrated example of ‘memberof’ call is equivalent to following code where returning type is explicitly declared:
MemberInfo<string> memberMetadata=memberof(Person.FullName);
Method's ‘FilterByEquality’ example still are not fully type safe, because returning collection items type is not detected from provided metadata. Problem can be solved by extending metadata containing types with one more generic parameter which will hold member containing object's type information.
This means: MemberInfo<T> extension to MemberInfo<TObject, TMember> where TMember refers to member's type and TObject refers to members containing object type:
Improved operator ‘memberof’ usage examples for C# programming language are demonstrated in
Taking into consideration previously described improvements to operator ‘memberof’, example with method ‘FilterByEquality’ can be declared as shown in
var wantedPersons=FilterByEquality(memberMetadata, personName);
It is possible that member access expression is invoked from existing member access expression. Consider example class declarations shown in
In case of two level member access expression (in example: instance.HomeAddress.Street) type of operator ‘memberof’ returning value should be member containing type from first member access expression. In example, first member access expression is ‘HomeAddress’ member access expression and its containing type is Person, so previous example can be rewritten without implicit type declaration as shown in
For multiple member access expressions to be useful as metadata, compiler should maintain whole chain of member access expressions. In previous example it means that variable ‘memberMetadata’ represents ‘Street’ member access expression and contains information that member ‘Street’ was accessed from ‘HomeAddress’ which is another member access expression. Member ‘HomeAddress’ was accessed from instance (not from another member access expressions), so here stops member access chain backtracking.
If is needed Address as returning type and we have only ‘Person’ instance, then multiple member access expression should be separated as shown in
Such multiple member access level behaviour of ‘memberof’ operator would be useful in defining queries.
Metadata can be gathered and then passed to methods, like in example shown in
Method parameter modifier ‘meta’ has 5 different forms:
Example of parameter modifier for field metadata access is shown in
Example of parameter modifier for property metadata access is shown in
Example of parameter modifier for method metadata access is shown in
Example of parameter modifier for constructor metadata access is shown in
Example of parameter modifier for event metadata access is shown in
Most benefits from method parameter modifier ‘meta’ usage can be gained in frameworks where reflection is used as architectural discipline, especially in frameworks supporting MVC architectural pattern where views usually are linked with models using binding mechanism which uses reflection. In
Best that is possible without operator ‘memberof’ invention is usage of lambda expressions as shown in
Finally, type member metadata access and usage syntax in all aspects are short, expressive and fully type safe. In
The only part that is not yet covered is method parameter modifier ‘meta’ for types (member containers). If method parameter modifier ‘meta’ works with type members, it should work with types as well.
This application claims the benefit of U.S. Provisional Application No. 61/603,342, filed 26 Feb. 2012.
Number | Date | Country | |
---|---|---|---|
61603342 | Feb 2012 | US |