Correct C # expectations for the future

Contact C # for a year. Overall is a very good language, but some of the details of the features 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. Assume that there is no generic type. We may need to use object and run the type conversion, or write a large number of identical code for each type. On a generic type constraint. C # as always strict. But because the generic constraints are not intact, sometimes you have to write some repetitive code. For example, here is a sample:

Public

static T-maxt (t A, T B) where T is int or long or float or double
{
return a = b? A:B;
}

Unfortunately today's C # does not have this function ... The System.Math approach is to write a Max method for each type.
About generic constraints in C # here: Constraints on type parameters, differences between templates and generics: differences between C + + templates and C # generics.

Access modifiers for namespace scopes
C # provides an internal access modifier to protect an assembly's internal type or member. But in practical development we often need to divide sub-modules in an assembly.

In order to make it clearer that the content exposed between classes within the same submodule differs from what is exposed between different submodules , it is hoped that the future C # will provide access to the namespace scope.

For example, here is a sample:

namespace Moudle
{
public class Common {...}
Private class Secret {...}
}

Add a private type of access modifier so that common can visit the Secret,secret type visible in the Moudle namespace, which is invisible outside of the moudle. Note that today's C # does not agree that elements within a namespace are declared private or protected.

Friends in C + + can solve the problem, but I guess you don't like friend ...
Using an inner class can solve the problem to some extent. But it's not free.

This problem is even more serious in Unity development, because the script component must be written in a separate file and cannot be an internal class.

A reference to a variable can be defined
C # supports referencing arguments using ref and out keyword on method parameters, which is important for struct types, otherwise it is very difficult to change the value of the structure itself by means of methods. But it may be to avoid the complexity of C #, so this feature is limited to method parameters. In this way we often encounter problems that look very abnormal. For example, the foreach traversal struct type collection cannot alter the value, and traversing the structure array with subscript can only use 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
Today's extension methods must be written in a separate static class. And the namespace must be used enough to use.

This is a meaningless limitation. We divide the code by functional modules and find that a method is more elegant to write in the form of an extension, 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 boring. Other than that. Extension methods do not support extending in the form of attributes, and do not support extensions in the form of references, and need 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
Look at this example:

using A.B;
Class MyClass {A.b.c.otherclass x;}

You need to write a long string of code as above without using any namespace, or you'll have to write a string with using a. Assuming that the namespace hierarchy is too long, you either using the namespace that the class is in, or writing the prefix from scratch.

It's not smart.

You want to recognize the child namespace correctly.

Using A.B;
Class MyClass {C.otherclass x;}

statement: This document comes from the "Dog Planing Learning Network" Community-unity Extreme College, is the Netizen self-published Unity3d study article, if there is any content violated your relevant interests, please communicate with the official. We will deal with it instantly.

Copyright notice: This article blog original articles, blogs, without consent, may not be reproduced.

Correct C # expectations for the future