A year of contact with C # is generally a perfect language, but some details are not perfect. Here is a note of some of the future expectations I have for it now.
More powerful generic constraints
Similar to C + + templates, C # generics make it easier to write code that works with multiple types. Without generics, we might need to use object and perform type conversions, or write large amounts of identical code for each type. C # is as strict as ever on generic type constraints, but because generic constraints are imperfect, sometimes you have to write repetitive code. For example, the following:
Public
static T-maxt (t A, T B) where T is int or long or float or double
{
return a = b? A:B;
}
Unfortunately, there is no such feature in C # now ... The System.Math approach is to write a Max method for each type.
the generic constraint reference for C # here: The constraints of type parameters, the difference between templates and generics: The difference between C + + templates and C # generics.
access adornments for namespace scopes
C # provides internal access modifiers to protect the internal types or members of an assembly, but in practice we often need to partition submodules in one assembly. In order to get a clearer picture ofwhat is exposed between classes within the same Submodulewith thecontent that is exposed between different sub-modulesThe difference is that you want the future C # to provide namespace-scoped access adornments. For example, the following:
namespace Moudle
{
public class Common {...}
Private class Secret {...}
}
add a private type of access adornment so that common can access the Secret,secret type visible in the Moudle namespace, which is invisible outside of the moudle. Note that today's C # does not allow elements within a namespace to be declared private or protected. Friends in C + + can also solve this problem, but I guess you don't like friend ...
using an inner class can solve this problem to some extent, but it is too free. This problem is more serious in Unity development because the script component must be written in a separate file and not be considered an internal class.
a reference to a variable can be defined
C # supports referencing arguments using the ref and out keywords on method parameters, which is important for struct types, otherwise it is difficult to modify the value of the structure itself by means of a method. But it may be to avoid the complexity of C #, so this feature is limited to method parameters. So we often encounter problems that look very unusual. For example, the foreach traversal struct type collection cannot modify the value, and traversing the structure array with subscript only uses the array name +. To avoid being too complex, you can limit the ability to define only a first-level reference.
foreach (ref Vector3 position in positions)
{
position.x = 0;
}
A freer way to extend
The extension method must now be written in a separate static class and must be used with a namespace. This is a meaningless limitation. We divide the code by functional modules, and find that a method uses an extended form to write more gracefully, so we have to take this method out and put it in a static class with a name that doesn't make sense. This is so boring! In addition, extension methods do not support extensions in the form of attributes, and extensions that are not supported in the form of references, are required to be improved.
class MyClass
{
public static dosomething (this Otherclass obj, ...) { ... }
public static getsetsomething (this otherclass obj) {get {...} set{...}}
public static void Modifyvalue (this ref ValueType value) {...}
}
More concise namespace usage rules
See this example:
using A.B;
Class MyClass {A.b.c.otherclass x;}
When you do not use any namespaces, you need to write a long string of code as above; using a, you still have to write a string. If the namespace hierarchy is too long, you are either using the namespace where the class resides or writing the prefix from scratch. It's not smart. You want the child namespace to be recognized correctly.
using A.B;
Class MyClass {C.otherclass x;}
Statement: This document comes from the "Dog Planing Learning Network" Community-unity Extreme College, is a self-published Unity3d study articles, if anything violates your relevant interests, please communicate with the official, we will deal with the real-time.
Expectations for the future of C #