C # Language Specification--1.13 version control

Specification | control

Versioning is a process that continues to improve components in a compatible manner. If the code that relies on earlier versions can be applied to a new version, the new version of the component is compatible with earlier versions of the source code. Conversely, if an application that relies on an earlier version can be applied to a new version without recompiling, the new version of the component is binary compatible.

Most languages do not support binary compatibility at all, and many languages do little to facilitate source code compatibility. In fact, some languages contain flaws that make the components that are developed with it in the process of continuous improvement, typically at least cause some client code that depends on the component to fail.

For example, consider the case of a base class author that publishes a class named base. In the first version, Base does not contain any F methods. The component named Derived derives from Base and introduces F. This Derived class is published to customers along with the Base class on which it relies, and customers are deployed to many clients and servers.

Author A
Namespace A
{
public class Base//version 1
{
}
}
Author B
Namespace B
{
Class Derived:a.base
{
public virtual void F () {
System.Console.WriteLine ("DERIVED.F");
}
}
}

From this point on, the issue of versioning begins to occur. The author of Base generates a new version with its own F method.

Author A
Namespace A
{
public class Base//Version 2
{
public virtual void F () {//Added in version 2
System.Console.WriteLine ("Base.F");
}
}
}

This new version of Base should be compatible with the original version in both source and binary terms. (If you add only a new method that yields a compatibility problem, the base class may never be improved.) Unfortunately, the new F in Base makes the meaning of Derived f ambiguous. Does Derived mean rewriting Base's F? This seems unlikely because Base is not F when compiling Derived! Also, if Derived's F does rewrite base's F, it must comply with the contract specified by base (this contract was not specified when writing Derived)! In some cases, this is not possible. For example, the F of base may require that its overrides always call the base method. Derived's F could not abide by such an agreement.

C # resolves this version issue by requiring developers to explicitly declare their intentions. In the original code example, the code is clear because Base does not even have an F. Obviously, because there is no base method named F, Derived F is a new method rather than an override of the base method.

If Base adds F and publishes a new version, it is clear what "Derived F" is in the binary version of Derived: it is semantically irrelevant and should not be treated as an override.

However, when recompiling Derived, its meaning is still unclear: Derived's author may intend to let its F rewrite Base F or hide it. Because the intent is not clear, the compiler generates a warning and, by default, makes Derived's F hide Base F. This compilation process results in semantic two semantics (compared to before recompiling Derived). The generated warning reminds Derived that the F method exists in the author Base.

If the F of Derived is semantically independent of Base F, then the author of Derived can represent this intent (and effectively turn off the warning) by using the New keyword in the declaration of F.

Author A
Namespace A
{
public class Base//Version 2
{
public virtual void F () {//Added in version 2
System.Console.WriteLine ("Base.F");
}
}
}
Author B
Namespace B
{
Class Derived:a.base//Version 2a:new
{
New public virtual void F () {
System.Console.WriteLine ("DERIVED.F");
}
}
}

On the other hand, the author of Derived, after further consideration, may decide that Derived F should rewrite Base F. You can specify this intent by using the Override keyword, as shown below.

Author A
Namespace A
{
public class Base//Version 2
{
public virtual void F () {//Added in version 2
System.Console.WriteLine ("Base.F");
}
}
}
Author B
Namespace B
{
Class Derived:a.base//Version 2b:override
{
public override void F () {
Base. F ();
System.Console.WriteLine ("DERIVED.F");
}
}
}

Another option for Derived authors is to change the name of F to avoid name collisions altogether. Although this change destroys Derived source code and binary compatibility, the importance of this compatibility varies by scenario. If you don't expose Derived to other programs, changing the name of F is probably a good idea because it improves the readability of your program, meaning that F doesn't have any confusion.