home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5074 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.3 KB
  1. Path: sparky!uunet!ulowell!m2c!bu.edu!inmet!spock!stt
  2. From: stt@spock.camb.inmet.com (Tucker Taft)
  3. Newsgroups: comp.object
  4. Subject: The definition of polymorphism
  5. Message-ID: <1993Jan26.223826.29345@inmet.camb.inmet.com>
  6. Date: 26 Jan 93 22:38:26 GMT
  7. Sender: news@inmet.camb.inmet.com
  8. Distribution: comp.object
  9. Organization: Intermetrics Inc, Cambridge MA
  10. Lines: 66
  11. Nntp-Posting-Host: spock
  12.  
  13.  
  14. In debating the meaning of polymorphism, it
  15. seems important to distinguish between where a
  16. *program* is polymorphic in some way, and where some *run-time*
  17. entity (like an object) is polymophic.
  18.  
  19. In many object-oriented systems, no object can change its
  20. underlying type/class at run time.  However, if you
  21. look at a program that manipulates objects, you find
  22. that a given name is used to reference (over different
  23. executions of the same piece of program text) objects
  24. of different underlying types/classes.
  25.  
  26. For a "conventional" strongly typed language like Ada 83, this kind
  27. of "polymorphism" doesn't happen, except inside some kind of
  28. explicit "template" or "generic."  This is compile-time parametric 
  29. polymorphism.
  30.  
  31. When you go from a conventional strongly typed language
  32. to an object-oriented strongly typed language (such as Ada 9X
  33. or Eiffel), you now find a single name within a given
  34. piece of program text refers to objects of different types/classes
  35. on different executions.  
  36.  
  37. However, because it is "strongly typed," we 
  38. do know *something* about the set of types for the objects
  39. that a given name might reference.  This might be called the
  40. "compile-time" type for the *name* (not the object), or the 
  41. "formal class" (or the "reference type" or ... -- standardization
  42. of terminology would help someday ;-).   
  43.  
  44. This "formal class" determines which operations
  45. are permitted (at compile-time) on the *name*, and generally 
  46. (at least in most simple type systems!) represents a lower bound on the
  47. set of operations defined for any *object* that might be referenced
  48. by the name at run-time.  This is run-time/dynamic (inclusion) 
  49. polymorphism.  (There is also run-time parametric polymorphism, though
  50. not as frequently in compiled languages.)
  51.  
  52. Now, back to a tentative definition of polymorphism:
  53.  
  54.    Polymorphism is where a given occurrence of a name within a given
  55.    piece of program text can refer to objects of different
  56.    types at run-time.  This polymorphism could be either
  57.    compile-time or run-time, and either parametric or inclusion.  
  58.  
  59. If the polymorphism is strongly typed, then the occurrence of the
  60. name has various compile-time attributes that represent a lower 
  61. bound on the properties of any possible object that will be referenced
  62. at run-time.  
  63.  
  64. (Note that the compile-time polymorphism inherent
  65.  in C++ templates is not strongly typed (until instantiation time), 
  66.  whereas the run-time polymorphism inherent in C++ class pointers 
  67.  and references is strongly typed.  In Eiffel and Ada 9X, both the 
  68.  compile-time and run-time polymorphism is strongly typed.)
  69.  
  70. (In addition to the above, there is "ad hoc" polymorphism
  71.  otherwise known as overloading, where two different occurrences of
  72.  the same name nevertheless resolve to be references
  73.  to different entities at *compile-time*, but that's not
  74.  usually of great interest when people discuss polymorphism.)
  75.  
  76. S. Tucker Taft   stt@inmet.com
  77. Intermetrics, Inc.
  78. Cambridge, MA  02138
  79.