The C # Essence and the CLR via C # Chinese translation are not unpleasant,

The C # Essence and the CLR via C # Chinese translation are not unpleasant,

C # Essence and CLR via C # are two good books. Teacher Zhou may be busy with things and he is too busy to translate.

If you are busy, don't take so many jobs.

Now we are talking about supply-side reform, and we are all vigorously advocating the craftsman spirit. We are doing technology, but we should be steadfast, right?

Compare the difference between the CLR via C # Translated by Mr. Li Jianzhong.

 

Here, we will only record the several problems we have discovered as an example.

In fact, Examples of improper translation similar to the following can be seen everywhere in these two Chinese translations. It doesn't matter if you don't go into it, but if you are seriously studying the two books, this ubiquitous flaw will greatly affect your reading experience and even your understanding of the original author's thoughts.

Teachers Zhou may not have read the two translations before they are published. Otherwise, how can they not be found and corrected if they are not logical?

When we learn the version translated by Mr. Li Jianzhong, it is like learning skills with two masters at the same time. The reader not only learns the knowledge from the original author, but also learns a lot of nutrition from the translator. He can also feel the rigorous and realistic nature of the translator.

What should I do when I read the translation of teacher Zhou? Read-Only Chinese translations cannot be understood. You can refer to the original Chinese translations at any time. A good book can't be found. If you lose trust in the translator, you must always be careful when reading it.

 

Of course, I have learned a lot from teacher Zhou's translation. Here, I just hope that Mr. Zhou can do a better job and contribute better products to help these C # learners.

 

C # Essence version 4

7.3.3 comparison between explicit and implicit Interfaces

Original article:

The key difference between implicit and explicit member interface implementation
Lies not in the syntax of the method declaration, but rather in
The ability to access the method by name through an instance of the type
Rather than via the interface.

Translations in the original book:

For implicit and explicit interface members, the key difference lies not in the syntax of member declaration, but in the ability to access members through type instances rather than interfaces.

It should mean:

An explicit or implicit method is used to implement interface members. The key difference is not that the syntax used to declare interface members is different,: the interface members implemented in implicit mode can be directly called by the Instance Object of the class. For an interface implemented in explicit mode, you must first convert the Instance Object of the class to the interface type before calling.

Section 7.5, page 224

Original article:

In contrast, implementing ISettingsProvider assumes that there is
Never a reason to have a class that can write settings without reading them.
The inheritance relationship between ISettingsProvider and IReadableSettingsProvider, therefore, forces the combined total of both interfaces on the ISettingsProvider class.

Translations in the original book:

On the contrary, the implementation of ISettingsProvider is based on the premise that no class can be written but cannot be read. Therefore, the inheritance relationships between ISettingsProvider and IReadableSettingsProvider force the two interfaces to be merged on the FileSettingsProvider class.

How can I merge the two interfaces?

The reason should be: ISettingsProvider designers inherit from IReadableSettingProvider, instead of providing the two interfaces to the user separately and in parallel. It is based on the following considerations: no class can be written but not
Read settings. Using the Inheritance Method forces the user to implement both interfaces at the same time (one write setting and one read setting ). If the two interfaces are provided to the user in parallel independently, the user may only implement the write interface instead of the read interface. This is not in line with the regular.

 

Page 1, about using interfaces to implement multi-Inheritance

Original article:

One possible improvement that works if the implemented members are methods (not properties) is to define interface extension methods for the additional functionality "derived" from the second base class. an extension method on IPerson cocould provide a method called VerifyCredentials (), for example, and all classes that implement IPerson-even an IPerson interface that had no members but just extension methods-wocould have a default implementation of VerifyCredentials (). what makes this approach viable is the fact that polymorphism is still available, as is overriding. overriding is supported because any instance implementation of a method will take priority over an extension method with the equivalent static signature.

Original book translation:

If the implemented member is a method (rather than an attribute), there is a way to improve it. Specifically, the interface extension method is defined for the additional functions derived from the second base class. For example, you can define the extension method Veri statement Credentials () for the on in the IPe (). In this way, all classes that implement IPerson (even if the IPerson interface has no members, only the extension method) will be implemented by the default Implementation of lerifyC Tuo dentials.This is feasible because of polymorphism and rewriting. Rewrite is supported because any instance implementation of the method takes precedence over the extension method with the same static signature.

I am not very clear about the ideas and technologies about polymorphism discussed in the original book, but I feel that this sentence added to the blacklist should be translated as follows:

This is feasible because the fact that the polymorphism mechanism remains effective when overriding is performed. Because the implementation of the Method Instance (that is, the Implementation defined in the class) has a higher priority than the implementation of the extension method with the same static signature.

I think the original article means this: When you rewrite the extension method with the same static signature as the interface method in the form of an instance method, because the instance method has a high priority, during use, instance methods are called preferentially, which achieves polymorphism. Therefore, it is feasible to use the interface extension method to implement multi-inheritance. This is because the multi-base class inheritance method perfectly supports polymorphism. If the multi-inheritance function is implemented using the interface extension method, polymorphism cannot be perfectly supported, this method is not feasible.

 

309 page title 11.2.2 simple generic class definition

Original article title: Defining a Simple Generic Class

The original author meant "defining a simple generic class ". This section uses a very simple generic class as an example to give readers a simple understanding of the definition of generic classes. Translated into a simple generic class definition. My first thought is that there is a generic class called a simple generic class. Then, I want to find a complex generic class.

 

Page 1 about generic parameters

Original article:

Note that it is legal, and indeed common, for the type argument for one generic type to be a type parameter of another

Original book translation:

Note that a generic type parameter can be another generic type parameter.

The translator can only understand the meaning of this sentence, and readers cannot understand it.

In the original article, the type parameter of a generic class can be used as the type parameter of another generic class.

In the translated text, the attributes are inconsistent. The front is generic, and the back is generic. This seems like intentionally bypassing the reader.

 

Page 7 interface constraints on Generics

Original article:

When calling a method on a value typed as a generic type parameter, the compiler checks whether the method matches any method on any of the interfaces declared as constraints.

Original book translation:

If the passed type argument is a value type, the compiler checks whether the method matches any method of any interface specified in the constraint when calling its method.

I am also drunk, can I be more rigorous? Do you understand the translation at least?

Value type, which should be value type. The author here is Value typed and the sentence is broken. The original text omitted two words, which should be: When calling a method on a value which is typed as a generic type parameter, the compiler checks whether the method matches any method on any of the interfaces declared as constraints. the value here should be variable, which is a variable and a value.

When a method is called as a variable passed in as a generic type, the compiler checks whether the method matches the methods defined by the interfaces specified in the interface constraints. The translation of this sentence should also refer to the context. In the original article, it is said that you do not need to convert a generic variable to an interface type to call an interface method in a generic method, even if the called method is explicitly implemented. (This is not possible in other contexts ). Therefore, this sentence only explains "you do not need to convert generic variables to interface types" and explains why you do not need to convert them.

 

331 page about covariant and Inverter

Original article:

An IPair <PdaItem> can contain an address, but the object is really a Pair <Contact> that can contain only contacts, not addresses. type safety is completely violated if unrestricted generic covariance is allowed.

Source Code related to the original text:

Contact contact1 = new Contact ("Princess Buttercup "),
Contact contact2 = new Contact ("Inigo Montoya ");
Pair <Contact> contacts = new Pair <Contact> (contact1, contact2 );
// This gives an error: Cannot convert type...
// But suppose it did not.
// IPair <PdaItem> pdaPair = (IPair <PdaItem>) contacts;
// This is perfectly legal, but not type-safe.
// PdaPair. First = new Address ("123 Sesame Street ");

 

Original book translation:

IPair <Pdaltem> can contain addresses, but the Pair <Contact> object can only contain contacts and cannot contain addresses. If unrestricted generic covariance is allowed, type security is completely insecure.

It is estimated that the translators do not know what they are talking about.

This sentence is indeed hard to understand. Especially the context of the book. In fact, the original author is not rigorous, leading to problems.

Throughout this book, we have been using the PdaItem class, Contact class, and several other classes as examples to explain various concepts. (In fact, I personally feel that these classes have far-fetched relationships and are not suitable for examples to explain various basic concepts ).

The Contact class has an address field, but the PdaItem class does not.

However, in the context, the address in this sentence (the first letter of the original book is incorrect, and the first letter is Address) actually refers to a class named Address, and this class inherits from PdaItem. However, the sample code is not described in the original book. This leads to confusion between the translator and other original readers.

After understanding this, the original article is easy to understand.

In the original article, IPair <PdaItem> can accommodate the Address object (because Address is derived from PdaItem). However, IPair <PdaItem> pdaPair itself is a Pair <Contact> object, only the Contact object can be accommodated, but not the Address object. This directly damages the type security.

There is a mistake in the original book, which is not a reasonable reason for your mistakes. Otherwise, you will not be able to spread it all over again.

In fact, the principle is very simple, that is, List <String> type variables, cannot be assigned to List <Object> type variables listObj. Because listObj is actually of the List <String> type, but literally it is of the List <Object> type. If a user puts an int variable in, isn't it a problem? This causes type insecurity.

 

 

 

 

 

You are welcome to reply to your questions. You can also post the unclear content in the original book for discussion. I will also update the problems found later here.

We hope that the two books of the next version will be more comprehensive and give readers a better feeling.