home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11461 < prev    next >
Encoding:
Text File  |  1992-07-23  |  7.6 KB  |  181 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@uunet.uu.net!mole-end
  4. Subject: A message forwarded to Jim Adcock
  5. Message-ID: <1992Jul23.174142.29983@uunet.uu.net!mole-end>
  6. Organization: :
  7. Date: Thu, 23 Jul 1992 17:41:42 GMT
  8. Lines: 171
  9.  
  10. >From fmccva!bms88!stuart  Wed Jul 22 22:58:21 1992 remote from uunet
  11.  
  12. >From: uunet!fmccva!bms88.BMSI.COM!stuart (Stuart D. Gathman)
  13.  
  14. An open letter to Jim Adcock,
  15. (This didn't get posted properly. You may wish to post if
  16. you think it is appropriate.)
  17.  
  18.  [So be it.  I don't entirely agree with the strength of the message, but
  19. I do agree with its sense.  I have performed some minor line-editing, but
  20. no token-editing. --mole-end!mat]
  21.  
  22. Dear Jim,
  23.  
  24. I have been following your (operator .) debate for some time now.  I
  25. basically agree with you.  I think that other people do also.  They
  26. probably wish they could admit this publicly without also admitting
  27. to abject stupidity.  Unfortunately, your postings have continued
  28. to reinforce "linkage" between these issues :-)  Believe it or not,
  29. others (including Stroustrup) have agreed with you on basic issues
  30. (not, of course, with your whole proposal).  Since you don't seem to
  31. have noticed, I will try (at the risk of my life and reputation) to 
  32.  
  33.   a) review basic agreement between all parties.
  34.   b) attempt to explain the (non-political) reasons why other
  35.      parties are reluctant to adopt your proposal right now.
  36.   c) present my own proposal :-)
  37.  
  38. I can sympathize with your frustration.  I make the same mistake on
  39. a regular basis, antagonizing my potential allies by single minded
  40. devotion to principle.  I have learned (but still have difficulty
  41. practicing) that relationships are in the long run more important
  42. than technical correctness.
  43.  
  44. IMHO, everyone seems to agree that
  45.  
  46.   "operator ." would be a good thing if properly defined.
  47.  
  48. Now, if everyone agrees on this, why did certain commitee members balk
  49. at your proposal the first time around (before you antagonized them)?  I
  50. am reading between the lines here, but I believe that they felt that your
  51. obvious and straightforward definition might compromise a better handling
  52. of *implicit* calls to "operator ." in the future.  They felt that there
  53. ought to be a better way, but didn't have time (or inclination after
  54. being called stupid fools) to think it through.
  55.  
  56. If I may try to summarize your proposal: you suggest that operator . should
  57. be applied only where explicitly written in a manner exactly analogous
  58. to operator -> .  
  59.  
  60.     a) This is simple
  61.     b) This is easy to implement (just remove the restriction as
  62.        you keep pointing out).  Some have already tried it with
  63.        good results.
  64.  
  65. However, there are many implicit calls to "operator .".  An obvious
  66. example are operators.  Under your proposal, one simply creates forwarding
  67. functions for the desired operators.  This is tedious, but straightforward.
  68. Unfortunately,
  69.  
  70.     a) This is tedious.
  71.     b) the potential operator combinations are unbounded with
  72.        repect to user defined types.  This makes it impossible to use
  73.        a template for a smart reference (for example).
  74.  
  75. I am sure that Stroustrup has thought about this more than I have.  In fact,
  76. I was angry when you removed the 2nd and 3rd alternatives from the analysis
  77. of your proposal -- "because they didn't correspond to my proposal".  What
  78. conceit!  As if your proposal is the only one that matters.  Perhaps I
  79. could have gleaned a better idea of what Stroustrup was thinking by reading
  80. what he considered to be alternatives to your proposal.
  81.  
  82. [Let me inject an opinion, and that is that the fewer options presented
  83.  to x3j16 in a proposal, the better, _in general_.  The more complete the
  84.  analysis, the more you may risk violation of this rule.--mole-end!mat]
  85.  
  86. Anyway, the tedium and unboundedness of forwarding functions don't sit
  87. right with me (or with Stroustrup either, apparently).  Perhaps there is
  88. a better way.  Perhaps not, but wouldn't it be awful if implementing the
  89. immediately obvious solution were to forever mar the better way when it is
  90. discovered?  If you want the committee to adopt an "operator ." proposal,
  91. you must 
  92.  
  93.   a) *motivate* them to think about the ideal solution until it 
  94.      crystallizes.  Implying that anyone who doesn't embrace
  95.      your proposal immediately is an idiot doesn't help this strategy.
  96.  
  97.     or
  98.  
  99.   b) convince them with a rigorous proof that no other solution
  100.      exists.
  101.  
  102. You may not think that a hypothetical ideal is worth pursuing when there
  103. are immediate benefits to be gained by removing the current ban on
  104. "operator .".  This is a matter of priorities - i.e. opinion.  Please
  105. repect Mr. Stroustrup's desire to create the ideal language.  After all,
  106. his reputation is on the line, not yours.
  107.  
  108. For example, here are some of my ideas on the ideal solution.  While they
  109. are probably full of holes, they will illustrate this point - note how my
  110. idea would break working legal programs using your "explicit call only" rule.
  111.  
  112.   a) "operator ." works analogously to "operator ->", returning a reference
  113.      or structure to which the "." is again applied.  However, there
  114.      are certain implicit uses for which there is no analogy with "operator ->".
  115.  
  116.      So in addition:
  117.  
  118.   b) a user defined "operator ." applies to *all* invokations, including
  119.      implicit invokation through operators.
  120.      
  121.      Except:
  122.  
  123.   c) an accessible member is invoked directly instead of "operator ."
  124.      - even a named member with an explicit dot.  For example,
  125.      member functions of a smart reference can refer to internal members
  126.      in the normal manner.  A smart reference can also override
  127.      specific members of the class "operator ." returns a reference to 
  128.      (the forwarded class).
  129.  
  130.   This is consistent with "operator ->" since the latter is never called
  131.   implicitly and other members are accessible in the normal manner.
  132.  
  133.   A useful smart reference class can have only one public member in addition
  134.   to constructors and destructors - "operator .".  Additional public members
  135.   can override particular operators or members for special circumstances
  136.   via rule (c).
  137.  
  138.   Rule (c) allows friend classes (and derived classes) to access internal
  139.   members of a smart reference.  Note that -> does not allow this since an
  140.   implicit call to "operator ." is eventually involved.
  141.  
  142.   A smart reference class implementation must be careful when referring to
  143.   members of the forwarded class through its own "operator .".  Its own
  144.   members will override the forwarded members.
  145.  
  146.   There is one aspect of my own proposal that doesn't sit right with me.
  147.   It makes member protection determine scope, whereas ideally, protection 
  148.   violations should result in compile time errors, not mysteriously
  149.   switching the reference to another class.  This can only happen, however,
  150.   with classes that overload "operator .".
  151.  
  152. While this definition of operator . may not be ideal either, the important
  153. thing to note is that
  154.  
  155.   a) it has properties that I consider desirable
  156.  
  157.   b) it breaks programs written according to the explicit invokation
  158.      only definition since not all explicit '.'s result in calls
  159.      to "operator .".
  160.  
  161.   c) it also claims exact analogy with "operator ->".
  162.  
  163. Apparently there is more than one (incompatible) way to be
  164. "exactly analogous to ->".
  165.  
  166. Do you see why rational C++ experts are afraid to jump on your bandwagon
  167. without careful thought?  If you want to see the ban on "operator ." removed
  168. from C++ sooner rather than later, you must make the individuals involved "want
  169. it so bad they can taste it", not "feel nauseated when the subject is
  170. mentioned". 
  171.  
  172.         Sincerely,
  173.  
  174.         stuart@bmsi.com
  175. [Forwarded by ]
  176. -- 
  177.  (This man's opinions are his own.)
  178.  From mole-end                Mark Terribile
  179.  
  180.  uunet!mole-end!mat, Somewhere in Matawan, NJ
  181.