home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / cplus / 993 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  6.0 KB

  1. Path: sparky!uunet!decwrl!bu.edu!Shiva.COM!world!wmm
  2. From: wmm@world.std.com (William M Miller)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Alternatives to operator.()
  5. Message-ID: <Bs6n59.GD@world.std.com>
  6. Date: 30 Jul 92 03:31:56 GMT
  7. References: <1992Jul23.024159.18039@microsoft.com> <BruME9.HGJ@world.std.com> <1992Jul27.204820.8400@microsoft.com>
  8. Organization: Software Emancipation Technology, Inc.
  9. Lines: 120
  10.  
  11. > |expr           addressing context      scope
  12. > |----           ------------------      -----
  13. > |(*xp).i        object to which xp      class X
  14. > |               points (indirection)
  15. > |
  16. > |xp->i          object to which xp      class X
  17. > |               points (indirection)
  18. > |
  19. > |In each case, you look up the name "i" in the implied scope, take the
  20. > |corresponding offset out of the symbol table, and add it to the base
  21. > |address implied by the addressing context.  
  22. > Your statement is incorrect in both the (*xp) and xp-> cases above,
  23.  
  24. So you assert, but I saw no argument to that effect in your posting.
  25.  
  26. > I keep making this point, and you keep ignoring it:
  27. > The language ALREADY permits operators *, &, and -> to be overloaded, yet
  28. > you keep making arguments pretending that these overloadable operators
  29. > don't ALREADY exist.
  30.  
  31. The reason I "ignore" this point is because it is irrelevant to the subject
  32. of the analysis I was making -- that built-in "." is different from built-in
  33. "->" because the former does not have a corresponding run-time operation,
  34. while the latter does.  Since the built-in "." has no runtime operation, it
  35. does not make sense, IMHO, to allow an overloaded operator.(), since
  36. overloaded operators are primarily runtime operations (calling a function to
  37. perform some action).  The built-in "->" _does_ perform a runtime operation
  38. (indirection), so providing an overloaded operator->() does make sense from
  39. this perspective.
  40.  
  41. >                                    we need overloadable operator.()
  42. > to ALLOW such relationships to continue to be made, in the face of
  43. > ALREADY overloadable operators &, * and ->
  44.  
  45. This is an unjustified conclusion.  What is needed is smart references,
  46. whether provided by operator.() or some other method.
  47.  
  48. > Wrong.  If this were my terminology, then in the following:
  49. >         px -> i;
  50. > would mean "i within the object referred to by px"
  51.  
  52. It does.
  53.  
  54. > which is clearly a false statement given that the language ALREADY
  55. > allows operator-> to be overloaded.
  56.  
  57. The action of an overloaded operator->() is irrelevant to this analysis of
  58. the meaning of the builtin operators.
  59.  
  60. > I have pointed out that there is a tiny fixed set of unary member operators
  61. > where ARM requires the LHS to be a member.
  62.  
  63. And those are only the beginning of the operators that may require
  64. forwarding functions.  In addition, all the compound assignment operators
  65. (+=, -=, etc.) are generally best provided as member operators.  Other
  66. operators may be included as members as well to prohibit conversions in
  67. operator contexts.  (And don't forget conversion operators, too, which must
  68. be members.)
  69.  
  70. > That's It.  Since there is such a small fixed set of possible functions, 
  71.  
  72. No, the set is unlimited because of argument overloading and conversion
  73. targets.
  74.  
  75. > BUT, what if the class implementor CHOOSES NOT to forward one of these 
  76. > operators?  What if a "smart reference" implementor CHOOSES that operator=()
  77. > should mean -- BY DEFAULT -- assign one smart reference to another
  78. > [such as references are implemented in just about all other OOPLS]
  79. >         ref1 = ref2;    // assign ref2 to ref1 NOT assign refed-ob2 to refed-ob1
  80. > Your position would prohibit such a CHOICE.
  81.  
  82. No, since my preference is for a solution in which members of the smart
  83. reference are chosen in preference to the target's members.  (Actually, the
  84. special rules for operator=() -- generated by the compiler rather than
  85. inherited from a base class -- require that smart reference classes provide
  86. operator=() regardless of which set of semantics is desired, but the point
  87. still applies to the other operators.)
  88.  
  89. >                                       Again, rather then keep making 
  90. > vacuous arguments that "my" proposal is "half-empty" why don't *you*
  91. > write down *your* counterproposal for how something, anything else would
  92. > work that is better.  Because right now, your counter-proposal is not
  93. > "half-empty" -- rather it is totally empty, because you have refused to
  94. > counter-suggest any CONCRETE counterproposal
  95.                      
  96. I freely agree that I have no counterproposal.  The reason is not "refusal"
  97. to write one but simple lack of time, both to explore fully the ideas I have
  98. and to write them down comprehensively if the exploration indicates that the
  99. effort of documenting them is warranted.  Perhaps in the fall something will
  100. be possible; in the meantime, part of the role of my criticism is to
  101. establish some of the criteria which a proposal would have to fulfill in
  102. order for me to consider it "better."
  103.  
  104. I continue to emphasize, though, that I'm not arguing against your proposal
  105. in favor of some other proposal but simply explaining the things I don't
  106. like, regardless of whether any other proposal ever comes down the pike.
  107. The issue is not, at the moment at least, whether your proposal is better
  108. than some other, but whether it's good enough.  Is your proposal better than
  109. the status quo?  Probably.  Is it enough better to warrant changing the
  110. language?  I'm not convinced, and the reasons are my three objections:
  111.  
  112. 1) It requires warping one's model of the language to attribute a runtime
  113. action to "." (to be fair, some people have apparently already acquired this
  114. warped view, so it's not a disadvantage for them :-)
  115.  
  116. 2) It leaves a bunch of forwarding functions still potentially required
  117.  
  118. 3) It requires doing something unobvious to access members of the smart
  119. reference (and, as has been pointed out, there are lots of ways of doing
  120. that, none obviously better than the others).                
  121.  
  122. The degree of importance one assigns to these issues in comparison to the
  123. benefits of the proposal is obviously a value judgment, but they do have to
  124. be considered.
  125.