Talk:Subtype
From Wikipedia, the free encyclopedia
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)
[edit] 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. --P3d0 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 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)
