Talk:Polymorphism (computer science)
From Academic Kids
Much of the stuff under "Subtyping polymorphism" (including most of the stuff I just added) does not belong under "Parametric polymorphism", but I don't have time to fix that right now. —Daniel Brockman 16:19, Jun 1, 2004 (UTC)
I've never come across ad-hoc polymorphism as described in the article (although of course I understand overloading and coercion), only the type described as parametric polymorphism. Seems to me that this could usefully be split into two sections: one on polymorphisms of data types and one on polymorphism of functions (in the broadest sense - to include procedures, members etc.).
A data type is polymorphic in that it has a member whose type may be parametric or ad-hoc (as per the article).
A type which is used to store a stack node would normally have two data members: the data held at a position in the stack and the next node below it. Manipulation of the stack itself doesn't need any knowledge of the data value type. How this type is applied to the stack node depends on the implementation language but falls neatly in the ad-hoc/parametric view explained in the article.
I think though that for functions (procedures, members etc.) there are three ways of looking at the issue which makes it easier to see what is going on:
- Inclusional polymorphism (called subtype polymorphism in the article) is where a function that expects (or returns) one type may in fact take or return any legal subtype.
- Parametric polymorphism is where the type is applied to the function in the source code (either explicitly or implicitly).
- Operational polymorphism is where the function assumes that some other function/operator will work on the type and the code is written in terms of that. This is the contract that a template implementation of, for example, min() works in C++ and is also the way that most object-based languages work.
C++ is rare in that it allows all of the three forms. I wouldn't consider overloading a type of polymorphism in the same way that the others are. It really is a way of looking operation polymorphism - the overload itself is not polymorphic, but the function that makes use of the overload is assuming operational polymorphism on the types that it is using.
--KayEss 02:13, 16 Sep 2004 (UTC)
- This isn't entirely consistent with the use of the terms I'm familiar with. I'm familiar with the term "parametric polymorphism" being applied to functions, and meaning roughly what you call "operational polymorphism". An ML "append-to-list" function is often described as parametric polymorphic, for example, since it can append an element to any type of list by being written generically using only operators that work on any type of list. --Delirium 14:53, Sep 16, 2004 (UTC)
- The operational polymorphism comes into its own in weakly typed languages (I was particularly thinking of JavaScript/ECMAScript/JScript here). You write a function that takes an argument for which you make certain assumptions about the members available on that object. My guess is that a C++ programmer would probably think about min() in an operationaly polymorphic way, although strictly, you're right, it is parametric polymorphism. It was a (badly chosen) example... I guess the use of a min macro would be nearer the mark --KayEss 12:49, 18 Sep 2004 (UTC)
| Contents |
History of the term
I think this article could be improved by adding a little history about the term. Should be noted that was Christopher Strachey who invented it in 1967, and is his definition which's showed here. Latter, in 1985, Cardelli and Wagner [1] (http://citeseer.ist.psu.edu/cardelli85understanding.html)refinedthat definition, adding the concept of universal polymorphism("true polymorphism").
Also should be noted that some authors(Booch and Rumbaugh) call polymorphism only to inclusion polymorphism or polymorphism of intheritance, which leads to misunderstandings.
All of this is explained in the [2] (http://burks.brighton.ac.uk/burks/pcinfo/progdocs/oofaq/)comp.object Usenet's group FAQ.
I would do by myself, but english is not mi first language and I'm a little afraid of doing something unintelligible :-(
Removed sentence
I removed the following recently-added sentence from the end of the very first paragraph:
- Polymorphism can be very useful in having many other applications use a common function or library, which is good because a function that does one thing does not have to be rewritten many different times to accomodate many datatypes.
It needs to be reformulated, but I'm not sure how. —Daniel Brockman 20:47, Dec 22, 2004 (UTC)
Whoever added it was right, though: something similar needs to be put there. —Daniel Brockman 20:50, Dec 22, 2004 (UTC)
I don't like polymorphism definitions based heavily on "types". Many OOP languages don't even have formal types.
- Well, then they don't really have polymorphism. :) Seriously, though, I take the opposite view to yours, and bristle when people use the word "polymorphism" for anything other than parametric polymorphism, which as far as I can tell makes no sense without types. I think this article is right to discuss the all the uses of the word that one finds in different communities of programmers, but I think it could do a better job in terms of overall coherence and explaining how the different meanings of "polymorphism" relate to each other. -- Cjoev 19:41, 29 Mar 2005 (UTC)
Type classes
I have removed the existing discussion of Haskell's type classes (from the subtype polymorphism section), and put a new bit about them in the ad-hoc polymorphism section. I'm not a Haskell expert; those who are may find things wrong with what I've done. There were several things wrong with the old paragraph on type classes that even I could see, including the fact that it was in the subtyping section. Here it is just in case anyone wants it:
"Haskell’s type system implements subtyping polymorphism using type classes. Analoguously to interfaces in Java, a type class declares a set of polymorphic operations that can be performed on any object whose type belongs to the class. This is then used to add constraints to types, limiting the set of objects that belong to them, while reciprocally expanding the set of things that can be done to the objects. For example, a list of ordered elements is typed (Ord a) => [a]. (The class Ord declares ordering relations such as =>, <, etc., and provides default implementations for most of them.)
"
-- Cjoev 20:51, 29 Mar 2005 (UTC)
Polymorphism and types
Here's my argument for stretching polymorphism beyond data types: the notion, I think, is wider. It's been alive for a very long time, even if it was conceived differently. (Abelson and Sussman call it "message-passing", for instance - and that was 1985!) In the end, polymorphism is polymorphism. --VKokielov 04:50, 12 Apr 2005 (UTC)
Proposed Merge from "Theoretical foundations..."
I think TakuyaMurata's proposed merge of the content from Theoretical foundation of polymorphism needs some discussion. (I hope I manage to start a debate rather than a flamewar here, but I may be on shaky ground...) In particular, before we move material from that article into this one we must answer the question: does that article mean the same thing by the word "polymorphism" as this one does? I say the relationship is at best unclear and needs to be clarified if the merger is to make this article better rather than less good. This article lists several different kinds of polymorphism, and I don't think that article is really talking about any of them: It's not about parametric polymorphism, because all the functions in the example have simple (i.e., monomorphic) types; it's not about subtype polymorphism, because there is no issue of one type containing or subsuming another; it's not about ad-hoc polymorphism, and it's not about coercion. Is there some other meaning of polymorphism we haven't covered yet?
Perhaps the abstract exposition in the other article is good even though the extended example forming the bulk of it misses the mark? Maybe, but I find it difficult to understand. I think it's mostly focused on the idea of abstraction rather than polymorphism. I realize the two are related, but their relationship is very deep and subtle and should be explained as carefully and clearly as possible -- if we're not ready to do that we should leave it alone.
Cjoev 18:24, 29 May 2005 (UTC)
Space between all and nothing
I have some problems with the statement at the top of the page, saying that there are two kinds of polymorphism. I find it neither practical, nor really fair: there is a lot of space between all and nothing.
Typically one wants to constrain polymorphism, so that the set of actual types is potentially infinite, yet partly specified. Types may be used to express these partial specifications: this is the role of hierarchies. Hence a third kind of polymorphism: allow to express constraints relevant to a specific context. Marc Girod 06:29, 1 Jun 2005 (UTC)
- This is a good point. Type classes, which are discussed briefly, are one form of this kind of constraint. Subtype-bounded polymorphism, which comes up all the time in type-theoretic studies of languages but I am ashamed to admit I don't really know the syntax for in any real language without looking it up, should also be mentioned but isn't. I think it should go somewhere under parametric polymorphism. Are there other forms of constraint as well? Cjoev 14:44, 1 Jun 2005 (UTC)
