C # Chief Architect: version control, virtualization, and coverage. Why is C # A non-virtual approach?

Abstract:This article is an interview with Bruce Eckel and Bill Venners on C # chief architect Anders hejlsberg. In this article, you will be able to understand why C # declares a non-virtualization method by default, instead, we adopt solutions opposite to those in Java and C ++, all of which are related to version control and method coverage. Default non-Virtualization

Bill Venners:In Java, the instance method is virtualized by default. It can be overwritten in the subclass only when it is explicitly declared as final. By default, the C # instance method is not virtualized. To declare a virtualization method, you must explicitly declare it as virtual. Why?

Anders hejlsberg:The reason is as follows:

First, performance. Through observation, we found that Java programmers often forget to declare methods as final when writing code, so these methods will be virtualized, so the performance is not good. Compared with the use of virtual methods, this will improve the performance. This is one of them.

More importantly, version control. There are two main ideas about Virtual Methods: one is academic. They think that "Everything should be virtualized, because I may overwrite it in the future "; the pragmatic School (from the real world to get the idea of developing applications) believes that "we only need to care about the necessary virtualization ".

When we virtualize something on the platform, we make too many assumptions and assumptions about future changes. For a non-virtualization method, X and Y occur when you call it. When a virtualization method is released in the API, not only does x and y occur when you call this method. We also guarantee that when you overwrite this method, it will be called in this specific sequence, and note that these status will not change.

Every time you use virtualization in the API, you are creating a callback hook. As an OS or API framework designer, pay more attention to these issues. You do not want users to reload and hook any part of the API, because you may not guarantee this. Similarly, people do not necessarily fully understand their own guarantees when declaring something through virtualization.

Incoming and outgoing contracts

Bill Venners:It sounds like you don't care whether the people who cover the method correctly implement the caller's guarantee. What you care about is the guarantee made to the people who cover the method.

Anders hejlsberg:In fact, I care about both of them. Virtualization involves two aspects: incoming and outgoing. People are good at thinking about incoming constraints, but do not have a clear understanding of outgoing.

Bill Venners:What do you mean by incoming and outgoing contracts?

Anders hejlsberg:The incoming contract refers to the constraint when calling a method. It ensures that I can deduce what I need and what to do after the method is returned before calling the method. The outgoing contract is used in the overwrite method. When most APIs cover virtualization methods, they are not good at recording what you want to do: What are the constant conditions before calling? What is the correct result? Which methods do you need not call from your own implementations? And so on. In my opinion, by default, all methods have qualified incoming and
Outgoing contract. Similarly, not everyone can write excellent documents for "when to override, what is the constant condition at this time.

I can show you a very common version control problem, which we actually found from Java's experience. Every time a new Java version library is developed, it will bring damage: When you want to introduce a new method to the base class, if the derived class has a method with the same name and returns a different type, it will no longer be able to compile and pass, but will cause a overwriting exception. This is because Java, C ++, and so on have not taken into account the programmer's Thoughts on Virtualization.

Two meanings of Virtualization

Anders hejlsberg:When you are talking about "virtualization", this means two things. If you do not integrate the same labeled method, this will be a new virtualization method. Or another case: it overwrites the inherited method.

From the focus of version control, it is very important for programmers to determine their own ideas when declaring a method as virtual. Overwrite an existing virtual method!

Therefore, C # does not have these version control problems I mentioned above, that is, the conflict between the base class and the category class we introduced earlier. Maybe you have already declared a virtualization method in your class. Now we have introduced a new virtualization method. Of course, this is okay. There are now two virtualization methods, two virtual function tables (vtbl) slots. Derivative functions are also hidden in the base functions, but this is no problem. The base function is no longer used when writing derivative functions, so it does not hide any problems with the new functions and everything runs normally.

Bruce Eckel:You often encounter this version control problem in practice, so you want to solve it? I remember you did something similar in Delphi.

Anders hejlsberg:Yes.

Bruce Eckel:Your perspective on language is different from that of other people I have interviewed. It is very pragmatic.

Anders hejlsberg:I have always considered myself a pragmatic person. It is interesting because version control will eventually become a major element of language design. It represents how you override the C # virtual method. Because of version control, the reload solution in C # is not the same as other methods I know. We use version control cross-validation whenever a special feature is designed. "How does version control change it? From the perspective of version control, how is this function ?" Most previous programming languages have not considered this aspect.

Bruce Eckel:Are you concerned about version control mainly because of the bad DLL?

Anders hejlsberg:Yes, because I have been observing the changes in programming languages over the years. 20-25 years ago, we only had a K memory fence. We had to discard the previous code every year and spend a year re-writing it, just in time for the release of the new version. So you don't need to think about reuse? What is version control? We need to rewrite the code every year.

However, this has passed and will never happen again. According to Moore's Law, we may not use all the storage capacity. Now we can spend less energy on more infrastructure, applications, and functions than we did before. As the system's life is also growing, Version Control is becoming more and more important.