Fourth, completely clear the boundary (continue to separate subclassing and subtyping)
In the second quarter, we discussed some of the methods of separating subclassing and subtyping, named Subclassing-ImphaTyping. Today's object-oriented languages, such as Java, C # all use this technology. In addition, there is a method of further separating subclassings and subtyping. This method called inheritance-is-not-subtyping is a greater extent, which is more convenient for the code over the connection between subclassing and subTyping.
It is largely due to people who want to use the SELF type in the anti-co-change position (such as the parameter of the SELF type). Of course, the cost of increasing inheritance is that the flexibility of Subsumption is reduced. When the SELF type appears at the position of the anti-co-change, Subclass no longer means subtype, so Subsumption does not exist.
Please consider the two types below:
ObjectType MAX IS
VAR N: Integer;
Method max (other: max): max;
END;
ObjectType MinMax IS
VAR N: Integer;
Method max (Other: minmax): MinMax;
Method min (Other: minmax): MinMax;
END;
Consider two classes:
Class Maxclass IS
VAR N: INTEGER: = 0;
Method Max (Other: Self): Self Is
IF self.n> Other.n the return self else return other end;
END;
END;
Subclass MinMaxclass of Maxclass Is
Method min (Other: Self): Self Is
IF self.n END; END; Method Min and max are binary because it operates two objects: Self and Other. Other types are the type of SELF appearing in the anti-co-change position. Note that method MAX has an anti-union parameter type Self, and it is inherited from class MaxClass to MinMaxClass. Very intuitive, class MaxClass corresponds to the type max; class minmaxclass corresponds to the type MinMax. In order to accurately represent this correspondence, we must redefine ObjectTypeOf for classes that contain members using the Self Type, so that ObjectTypeof (MaxClass) = max ObjectTypeOf (MinMaxClass) = MinMax. In order to set the above equation, we map the SELF type in the class to the type name itself in the ObjectType. We simultaneously let the SELF type in inheritance. In this example, when we map the type of MinMaxClass, we map the SELF type in the inheritance Max method to the MinMax type. For the Self type of the Max method in MaxClass, we use the MAX type. In this way, we can get, any object generated by MaxClass, has a max type. The objects generated by any MinMaxClass have a minmax type. Although MinMaxClass is a subclass of MaxClass, it is not a subtype of Max here. For example, if we assume that subtype is established in this case, then the following: Subclass MinMaxclass' of MinMaxClass Is OVERRIDE MAX (Other: Self): Self Is If other. min (self) = iv. 中; =; END; END; According to our map rules and structural Subtype rules, ObjectTypeOf (MinMaxclass') = MinMax, so we can know MM ': MinMax for any MinMaxClass'. And if MinMax <: max is established, we can introduce mm ': max. So when we call MM'.max (m), m can be any object of any max type. However, when the MAX method is called other.min (Self), if this other does not have a min method, this method will fail. This shows that MinMax <: max is not established. Subclass (Subclass) no longer has the nature of Subtype when using the anti-co-change SELF type. V. Object Protocol From the discussion of the previous section, we see a class that uses the anti-Association of self type, Subclass is no longer subtype. This is a disappointable result. After all, many exciting object-oriented advantages are achieved by subtype, subsumption. However, fortunately, although we lost Subtype, we can also dig some things that can be used as compensation. Just, it's not like Subtype, we can't enjoy Subsumption. Let us study this new relationship. In the example of MinMax in the fourth quarter, Subtype is no longer established; simply uses generics, introduced Objectoperator P [M <: max] is ... End; there is also no use. P [MAX] is established, but p [minmax] is illegal because MinMax <: max is not established. However, in an intuitive look, any object that supports this protocol of MinMax, also supports the Max protocol (although we still don't know what this "agreement" is something). So, it seems that the guy called the "Subprotocol" is striving to us. In order to find the relationship of this sub-protocol, let's define two Type Operator first (still remember? It is a function on the type): Objectoperator MaxProtocol [x] IS VAR N: Integer; Method max (other: x): x; END; Objectoperator minmaxprotocol [x] IS VAR N: Integer; Method max (other: x): x; Method min (other: x): x; END; This way, max = maxprotocol [max], minmax = minmaxprotocol [minmax] More general, we can define: What = What -Protocol [What] Remember the fixpoint in lamda-cagculus? Given a function f, f (fixpoint (f)) = fixpoint (f) In the Type Operator in our sub-agreement, if we think that Type Operator is a function that acts on the type, then "What" is "What -Protocol" function's fixpoint! That is to say: What = fixpoint (What -Protocol). In addition to the nature of the above FixPoint, we also found the relationship between Max and MinMax. First, MinMax is a post-fixpoint of MaxProtocol, namely: MinMax <: maxprotocol [minmax] Second, we can see: MinMaxProtocol [MAX] <: maxprotocol [max] MinMaxProtocol [MinMax] <: maxprotocol [minmax] Finally, if we use <:: to represent a higher order child type relationship: P <:: p 'When and only when P [T] <: p' [t] Then, MinMaxProtocol <:: MaxProtocol. For the definition of sub-protocols, we can take the above <:: definition, namely: If S-Protocol <:: T-protocol, we call the type S and type T are a sub-protocol relationship. (1) We can also use this high-level relationship, still use the relationship of this subtype: If S <: T-Protocol [S], we call the type S and type T are a sub-protocol relationship. (2) In fact, the first definition seems to be more intuitive, which clearly shows that the sub-protocol relationship is the relationship between the type operator on the type, not the relationship between the type. Using generic technology, if we need to instantiate a type that implements MaxProtocol, we can use one of the following two methods: Objectoperator P1 [x <: maxprotocol [x]] is ... end; (1) Objectoperator P2 [P <:: MaxProtocol] IS ... END; (2) These two methods are the same in expression. The first method is called F-Bounded Parameterization. (Translator pressed, Generic Java said this method); the second method is called Higher-Order Bounded Parameterization. For the implementation of specific languages, for convenience, we can hide this Type Operator. Syntax can directly support the relationship of SubProtocol (represented by <#.). For our MinMax example, we have: Minmax <# max. (The translator presses, around a large circle, what FixPoint, post-fixed, what is the high-level relationship, I hope that you have not wrapped you. In fact, you only need to remember MinMax <# max, eight or nine do not leave ten Ha ha) <# This relationship does not have the nature of Subsumption, so you can't expect to get the polymorphic in the traditional OO. However, combined with generics, it is very useful. For example, we can give us all the GP-based fast sort template functions that you are passing to me for the parameters to give this constraint: the type used to instantiate this template function must support the Compable protocol. (Translator pressed, using it for the type security of the template in C . In fact, for the program that uses GP, maybe the sub-protocol constraint is more reasonable than the child type. Subbed SUMBSUMPTION requires polymorphism, ie Dynamic Dispatch. But many times, we don't necessarily need type parameters to support polymorphism. Please see my 文: http://www.allaboutprogram.com/bb/viewtopic.php? t = 255) Thinking: 1. Java is an Array that supports CoVariant. You can use a String [] type object as an object [] type. So, is Java's COVARIANT ARRRAY? Is it safe? why? 2. Everyone knows the type of relationship between the classic rectangle and the square? Between the squares and rectangles supporting the GET, SET, there is no Subtype's relationship because Subsumption is unsafe to get or set operations. However, if the square and rectangles are impossible to have subtype relationships? If the type of rectangle supports GET, what is the result? If the square only supports SET, what is the result? Next chapter: Object-oriented language based on objects.
