types, transformations, arrays, covariance, and others

types, transformations, arrays, covariance, and others

In order to simplify the narrative, define a few terms that are used:

Function: The abstract body of the output can be given, and variables can be considered as parameterless functions. For a member function or a more accustomed function called a method, I think it is a function that implies an object argument.

Type system is now the core and cornerstone of OO language. The type system is the basis of guaranteeing correctness, the current programming language mostly emphasizes static security, in fact, compile-time type correctness. The dynamic type system corresponds to the run-time type check to ensure the type correctness of the runtime. What is often called security is the type correctness.

Type conversions are blatant contempt for the type system. It's not safe. Many problems may be introduced. Sometimes, we may feel the need for type conversion, but that is the illusion that we can define a function that accepts some type of object and returns an object of another type. Therefore, the type conversion is not necessary. Some would say that you think of the type conversion as some kind of strange function call. I admit, this idea is good, but there are two flaws, one, the type conversion is more bullies than the function, capable of many functions can not do. Second, the type conversion sometimes occurs automatically.

arrays, a common language construct, which is supported by most languages. It is generally defined as a bunch of objects of the same type and can be used to claim any one of the heap objects by index. Many languages have a name for this pile of objects and are claimed by the [index] operation. However, there are many languages that do not support arrays as a class construct. The reason is that they think that an array is nothing more than an object, it contains several other objects, and this object, which contains multiple other objects, is generally called a container. Another view is that arrays are nothing more than functions. It completes a mapping from index to object. Either way, the idea is stronger than the original array, and it's easier to add some ancillary features such as boundary checks. Of course, this seems to imply that the introduction of [] is worthless. () on the line. Hehe, basic AH.

Static type checking alone is not enough. One of the most common examples is the list, which if we require a static check, then it is possible to ask us to either loosen the object type that the list container holds (that is, generalize, generalize (which is the same concept of Ghent and inheritance, do not connect to generics), or strongly limit the ability of a list. For example: A list, place the parrot in its even position, place an elephant in an odd position, and if it is a complete static type check, then we might say: we have a list of animals to put in, but it's easy for us to put an ant in. And the type system is not able to prevent this behavior. Actually caused the correctness.

Covariance (covariance), resistance to change (contravariance) and invariant (nonvariance) are the most controversial topics in oo theory. But they are so important and basic that they must not be said. They are closely related to the inheritance of polymorphism. At the same time, they will also involve how to solve the list mentioned above.

The so-called covariant, is the same with the main type of change. Therefore, it is called "Association". Or an example of how clear:

Class Animal

{

Public

Marry (Animal another);

};

Class Elephant:public Animal

{

Public

Marry (Elephant another);

};

Class Fox:public Animal

{

Public

Marry (Fox another);

};

Among them, the parameter another of marry is covariant. You may think, gee, this is not very good. In fact, there are many other arguments about the covariance of parameters. In general, most people think that parameters should be anti-variable, so what is anti-change? Anti-change, also called inversion, meaning that the function parameter of the subtype should be the parent type of the function parameters of the parent types, here a little bit around, look clearly, oh, and so you understand this sentence, you will think this is not intuitive, right? But, in fact, the sentence is right and in the general sense it is right. Let me give you an example:

You are a printing service provider, you promise to customers can accept TXT and PS format files, return a pile of printed paper, with TXT or PS file description of the content.

Later, you want to upgrade, you have added a file format PDF, you are not wrong, you can win new customers, but if you say I want to cancel TXT file format, then your customer may complain about you. In other words, you can only relax the type of argument you accept (generalization, parent class, etc.), but narrowing (specialization, subclasses, etc.) can result in a sudden failure of something that works.

Now you may think that parameter resistance is reasonable and should be. But don't worry, think of the previous example, is it true that animals and animals are married, and that elephants should marry animals or higher-class creatures? Yes, this is a problem, you may think that this may be a special case, but in fact it is universal, recall our member function (method), we will find that the function has an implied this parameter has been covariant. In addition, the return value type of the function is covariant, which is almost uncontroversial. As the example above, you give your customer a bunch of paper that prints the content, and if you change it to a subclass, a bunch of good paper that prints the content, your client won't object. For variables, I've said that it's just a return value for a function without parameters, so it seems to imply that they should be covariant.

There are more complex problems. Like the animal type system above us, we have a function called eating, animals eat food, elephants eat grass, foxes eat meat. That's what it's supposed to be. Co-change it. So, we have no way of deciding what to do about it. What the hell is going on. Continue to see:)

Now introduce a concept, assign (Dispatch). Dispatch is actually a function call. But it's a little bit more complicated: it chooses a specific function to implement the call according to its parameter type.

motor* m = new ... ();

M->run ();

This run is a function. The actual type of the call to run, which depends on the M parameter (M is actually the implied this parameter), is the assignment. Obviously, we are the basis of the multi-state in Oo, and there is a term called double-allocation, in fact, according to two parameters to determine the call that function, of course, there is more than one allocation of this argument.

A certain Daniel (can't remember what to call, sorry AH) after the study finally said: a function, those who decide to assign the parameters should be covariant, and other parameters should be reversed. See here, hand stroking forehead, suddenly dawned ah. So it should be so, not so. Oh.

Above involved Saga said a chase, found no mention of dynamic type related things, now talk about it. The construction of a dynamic type in C + + is called rtti--run-time type information. About this there are two operations, one called dynamic_cast<t*> (PO), one is the infamous typeid. The first action is to get the actual type information at run time, and of course it is possible to fail. For example: An animal whose actual type is an ant, but I want to transform it into an elephant by dynamic_cast when I am running, this is certainly not possible. But we can do this, and if we fail, we can get some kind of information, right? For typeID, I will not say anything else, its enhanced version is typeof, in fact, all support the reflection of the basic mechanism of the language, this thing is generally considered to be irregular:), but it does in some way increase our ability to express.