home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5041 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  6.3 KB
  1. From: kers@hplb.hpl.hp.com (Chris Dollin)
  2. Date: Mon, 25 Jan 1993 11:22:53 GMT
  3. Subject: Re: Re: FAQ  Part 1 (of 2) [ polymorphism or latent typing? ]
  4. Message-ID: <KERS.93Jan25112253@cdollin.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!usc!sdd.hp.com!hpscit.sc.hp.com!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  7. Newsgroups: comp.object
  8. References: <PCG.93Jan20002119@decb.aber.ac.uk> <1993Jan22.004420.16674@netcom.com> <KERS.93Jan22101155@cdollin.hpl.hp.com> <1993Jan23.0622
  9. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  10. Lines: 135
  11. In-Reply-To: objsys@netcom.com's message of 23 Jan 93 06:22:35 GMT
  12. Nntp-Posting-Host: cdollin.hpl.hp.com
  13.  
  14. In article ... objsys@netcom.com (Bob Hathaway) writes:
  15.  
  16.    In article ... kers@hplb.hpl.hp.com (Chris Dollin) writes:
  17.    >In article ...Bob Hathaway <objsys@netcom.com> writes:
  18.    >
  19.    >   Since Strachey defined parametrically polymorphic
  20.    >   functions (functions parameterized by objects of different types), the
  21.    >   formal parameters assume many forms and can be referred to as 
  22.    >   polymorphic.
  23.    >
  24.    >Yes; and formal parameters are not objects. (Digression to meta-discussion
  25.    >about how the compiler might treat the code would be irrelevant.)
  26.  
  27.    Actually, in C++ formals are objects.  
  28.  
  29. We are (as usual) arguing about terminology, then.
  30.  
  31. Formal parameters are not objects; they are names, standing for [references
  32. to] objects. 
  33.  
  34.    As I already discussed, parameter
  35.    assignment is considered an initialization of a declaration, an object
  36.    declaration.  
  37.  
  38. Yes; this equivalence principle arises by consideration of the \-calculus;
  39. I first came across it at Oxford, and it has been promoted by Tennant. 
  40. (Tennent? Rats. He did one of the books in the Prentice-Hall series.)
  41.  
  42.    If the declarator specifies a reference or pointer *object*, this
  43.    object is polymorphic.  
  44.  
  45. OK, so that's the way you want to use the term. (Incidentally, C++ seems to
  46. use the term ``object'' to refer to ``a region of storage''(ARM, p13), so
  47. I would be wary about using C++ terminology in an OO discussion without
  48. further clarification.)
  49.  
  50.    If you want to argue that in some languages, such as
  51.    Smalltalk, that names or entities are not objects but denote them, thats a
  52.    subtle difference, since pointers and references (or the names or entities)
  53.    *are* objects in some languages, simply objects that denote other objects.
  54.  
  55. I wanted to avoid any such argument.
  56.  
  57.    You won't be able to program in languages with pointers if you don't
  58.    understand this.
  59.  
  60. How fortunate I am, then, to have a proof of my understanding.
  61.  
  62.    Anyway, I see the point that the denoted objects are the
  63.    ones of *primary* interest, and perhaps I should change my definition to
  64.    emphasize that the references are polymorphic and not the interesting (?)
  65.    objects themselves (sorry piercarlo).
  66.  
  67. That would make your intent clearer, although I sxpect Piercarlo would still
  68. disagree with you, now for different reasons.
  69.  
  70. You said:
  71.  
  72. >I think you're the one inflicting confusing terminology.  Everyone in recent
  73. >  history seems to define polymorphism as a property of objects (Stroustrup,
  74. >   Meyer, Booch, ...) 
  75. >
  76.  
  77. So I said:
  78.  
  79. >I think this is because you have conflated the notions of ``objects'' and
  80. >``variable'' (or reference, or pointer, or whatever).
  81.  
  82. To which you replied:
  83.  
  84.   This is completely wrong because it is out of context.  
  85.  
  86. I don't think so; you were quoting other peoples definitions in support
  87. of a position that polymorphism was a property of objects, when it was
  88. clear (to me) that it was *entities* that were polymorphic [could stand
  89. for objects of different, probably related, classes], and that this was
  90. true even -- or especially -- when entites and objects were distinct
  91. kinds of things.
  92.  
  93.   Piercarlo was arguing
  94.   that either procedures (??) or objects "becoming" other objects defines
  95.   polymorphism, and that is what I was disagreeing with. 
  96.  
  97. I understood him to be arguing that *your definition* of polymorphism was
  98. in terms of ``becomming'' (and I agree that it was) and that this was not
  99. the notion of polymorphism endemic in the OO world (and I agree with this,
  100. too). If you change your definition to say that it is the *references*
  101. that are polymorphic, you have disposed of his first argument, leaving
  102. only the second (which is now, do we apply the term ``polymorphic'' to
  103. the methods or the entities? Formally or informally? In all languages
  104. or not?)
  105.  
  106.   He argued against
  107.   Meyer, Booch, and me completely - names, entities, objects and all - stating
  108.   our intention of polymorphism is wrong and should be referred to instead as
  109.   "latent typing".  
  110.  
  111. I think he was arguing against *your* perception of what polymorphism
  112. means. I also think he sees many different ways in which the concept of
  113. polymorphism can be applied, and takes the trouble to distinguish them.
  114. ``Latent typing'' means that the type of a variable (entity; name;
  115. whatever) is not fixed at compiletime, but can vary at run-time; the 
  116. actual type belongs to the referenced object. 
  117.  
  118. Languages with latent types (such as Pop, Smalltalk, Lisp) can implement
  119. polymorphic methods (eg, head, tail, sort) with no additional machinery.
  120. They can also do things that method-polymorphism cannot.
  121.  
  122. Languages with method-polymorphism need additional type rules to accomodate
  123. it. They gain a certain amount of security at the cost of expressiveness.
  124.  
  125.   I hope I've presented enough information to show *we* are
  126.   correct!  
  127.  
  128. No, between you you've presented enough information to show that you-plural
  129. are in danger of fighting a battle over names.
  130.  
  131.    And his anachronistic views on the functional implementation of the
  132.    object model and then using a functional view of values on top IMHO seems to
  133.    have confused the ganoozga's out of everyone in this newsgroup.  
  134.  
  135. Not everyone.
  136.  
  137.    At least I push the object model [and history has shown both you and 
  138.    piercarlo often haven't, if I may take sides].
  139.  
  140. Why does ``pushing'' the object model have intrinsic value? In our last
  141. prolonged debate (which I assure everyone I have no intention of
  142. regenerating) I plumped for pluralism and acknowledging that other
  143. computational (and world) models had something worthwhile to say. I did
  144. *not* run down the object model; I was criticising excessive naive
  145. application of it.
  146. --
  147.  
  148. Kers.       | "A foolish hobgoblin has the consistency of little minds".
  149.