Talk:Subtyping

Little sense

I am not implying that the author has no idea at all, but this article makes little sense. I am especially puzzled by the discussion of subclasses. My guess is that he is confused with the idea of typing and implementation. A subtype is more of typing issue, whereas subclassing is to create a new class based on an existing one. Am I the one who is missing something? (Of course, the previous version was not good either.) -- Taku 21:00, Mar 23, 2005 (UTC)

I'm sorry if what I wrote does not make sense, but I think it can be fixed. We may agree more than you think about subclasses. That paragraph was not supposed to be a definition, but an example. It is a fact that in C++, Java, C#, and just about every other statically-typed class-based object-oriented language I can think of, if A inherits from B, directly or indirectly, then A is a subtype of B. (To be pedantic, if the class A inherits from the class B, then the type A is a subtype of the type B -- in the languages I'm speaking of the distinction between classes and types is unfortunately blurred.) Perhaps it is a design flaw in these languages that they link subclassing and subtyping so closely (I hold this opinion), but nevertheless it's a very familiar phenomenon.

One place where I may indeed have crossed the line into implementation is in the inclusive/coercive distinction. Thinking about it again, of course this is a matter of implementation -- I was temporarily distracted from this by the fact that subtyping in some languages is almost trivial to implement inclusively, while subtyping in other languages is almost impossible to implement inclusively and must be coercive (int <: float is a good example).

The nominal/structural distinction is, I think, well known. It is also very important, because type theorists tend to work almost exclusively with structural theories of subtyping but many programming languages (notably class-based OO languages, as I discussed) use nominal subtyping. The terminology may not be standard, but if it's not then I don't think there is any standard terminology; perhaps the words should not be in boldface.

My personal opinion is that the (admittedly, extremely common) usage of the word "polymorphism" to describe the use of subtyping to make one's code more flexible (as in your example) is incorrect. Certainly, it is at best one form of polymorphism. -- Cjoev 15:55, 24 Mar 2005 (UTC)

I have changed the inclusive/coercive paragraph to emphasize that it's a matter of implementation. I also rephrased the text around the code example slightly. You can put it back if you like your way better. -- Cjoev 16:15, 24 Mar 2005 (UTC)

Funny, this reply makes much more sense than the article per se (like your mention of C++ instead of class-based OOP). I think we need to use more concrete examples. Now with your help, I understand the article better, but we can't expect people have a correct understanding of subclassing in the type theory. In other words, I am suspecting that the example of subclassing makes sense only for those who already know the stuff. As for subtyping and polymorphism, my intent, if largely inadequate, is to clarify the confusion between subtyping and polymorphism. It seems to me most people understand subtyping in the form of polymorphism, for good or bad. Anyhow, I think it's better to define what is a subtype correctly (both from type theory and practical usage, and give some examples. (At least please know that I know you know the stuff very well.) -- Taku 22:09, Mar 25, 2005 (UTC)

I think I see what you mean. Perhaps, among other changes, we should have the numerical example first and the subclass example second. The subclass example could be a little more concrete and a little more accurate: for example, it could mention certain OO languages by name (e.g. C++, C#, Java) -- but if we mention those languages by name it would be good to be careful that everything we say about them is true. (For example, in Java one can get a subtype either by "inheriting" a class or by "implementing" an interface. In C++ if A is a subclass of B then it's the pointer types (A *) and (B *) that are in the subtype relation, not the types A and B themselves. I don't know much about C# but I'm sure it has its own idiosyncracies.) The type theory part of the article should be expanded as well. As for polymorphism, I suggest that we could mention in this article that the two are often confused and leave it to the article on polymorphism (which addresses many different "kinds" of polymorphism including subtype polymorphism) to explain the difference between them. -- Cjoev 17:45, 28 Mar 2005 (UTC)

Move to "subtype and derived type"

I disagree with the move from "subtype" to "subtype and derived type". These two distinct concepts should have separate articles. --Doradus 04:22, May 24, 2005 (UTC)

I agree they should have separate articles in the future but since derived type was quite short, I don't see a need to talk it in a different article in this moment. After all, we have to discuss the difference between subtype and derived types. -- Taku 06:09, May 24, 2005 (UTC)

I disagree. A short article is called a stub. It's perfectly acceptable. It makes no sense to regress an article away from the state it should eventually reach. --Doradus 15:58, May 29, 2005 (UTC)

I am reverting my move. I tried to add the discussion between the difference between the two, but I couldn't explain it well (I know they are not the same.) -- Taku 12:50, May 31, 2005 (UTC)

The "bird example" appears to me like turning things upside down: The existence of different animals that have some characteristics in common has imho lead to the creation of the more general concept called "bird". But the article describes that the "generic object "bird" (or, supertype) gives rise to three derived objects (or, subtypes) "duck", "cuckoo" and "ostrich"." --- These particular types of birds, as well as others, exist independently from the "supertype" bird. If anything has derived from something, it would be the "superclass" bird which has been created in the process of observing different types of animals with common characteristics and attempting to generalize. The diagram used even shows "bird" as "derived" from the different types of animals.

What I fail to understand is that: "if A is a subclass of B, then an instance of class A may be used in any context where an instance of type B is expected". This would mean, for example, that all types of birds would have to be able to swim and to dive like ducks can. As for classes, I fail to see in which way A would be a subclass of B, for A would have to have at least all characteristics of B in order to allow full substitution. A could even have more characteristics than B, so that B could not be used as a substitute for A in any case. What would this make of B? Maybe my understanding is flawed; is it actually the intention of this article to explain that a subclass can be "superior" to its superclass, and that it must be at least as extensive (in its datatypes, for instances of subtypes) as its superclass to allow full substitution? How much does the extend of substitutability depend on the (rest of) the programming, like: The rest of the programming is not (or is) demanding a cuckoo to swim or to dive, though (or because) "cuckoo" is a subclass of "bird"? --- Lee-0 (talk) 13:35, 17 January 2008 (UTC)

Behavioral subtyping

The article has been tagged with an {{expert-subject}} tag for no stated reason. Based on the edit history of the user who tagged it, the complaint seems to be the lack of discussion of "behavioral subtyping". As far I can tell, that simply means covariance/contravariance of arguments/return type of methods (that is function types). So, this article is not missing anything fundamental in that respect, except the typing rule for function subtyping and its OOP nickname. I'll add that to the article shortly. Pcap ping 17:56, 25 August 2009 (UTC)

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was consensus to move to subtype polymorphism --PBS (talk) 20:00, 5 September 2009 (UTC) Subtype → ? —

• The name of the concept is "subtyping" or "subtype polymorphism" as evidenced by the references cited in article. So, I think it is better to have this article called subyping (or subtype polymorphism if you want to be more explicit) than arbitrarily picking "subtype" (or "supertype") as the name of the article.]] — Pcap ping 05:07, 26 August 2009 (UTC)

• Wow, I haven't heard this term in a while... anyway, yea, Support for subtype polymorphism.
  — V = I * R (talk) 07:25, 26 August 2009 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Intro Diagram

What do you guys think of adding an intro diagram? The text intro makes no sense to me. A diagram would or could convey the message nicely. Something similar or same as bird diagram. Thanks, Daniel.Cardenas (talk) 18:49, 11 June 2012 (UTC)

Transitivity of subtyping

Is this really true? Consider C++, certainly a prevalent and influential enough language that it seems unlikely something that fails there is true in almost all type systems. However, in C++'s coercive subtyping system (source: https://en.cppreference.com/w/cpp/language/implicit_conversion), only a single user-defined conversion is permitted; thus, such user-defined conversions define a subtyping system that is not transitive. 66.108.29.234 (talk) 12:43, 13 July 2022 (UTC)

First, "coercive", as used in section Subtyping#Subtyping_schemes, is a property of a particular implementation, not of the source language; hence C++ can't be coercive in that sense.

Second, I'm not aware that C++ "define(s) a subtyping relation" (however, I'm not very familiar with all details of C++). If I'm right, the sentence about transitivity wouldn't apply to C++, anyway. - Jochen Burghardt (talk) 08:15, 14 July 2022 (UTC)