home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11308 < prev    next >
Encoding:
Text File  |  1992-07-21  |  3.3 KB  |  72 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end
  4. Subject: Re: Speed, Correctness, Availability, and the Real World
  5. Message-ID: <1992Jul21.134143.20911@mole-end>
  6. Organization: :
  7. References: <1992Jul10.212014.4869@mksol.dseg.ti.com> <1992Jul21.011256.1404@microsoft.com>
  8. Date: Tue, 21 Jul 1992 13:41:43 GMT
  9. Lines: 61
  10.  
  11. In article <1992Jul21.011256.1404@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
  12. > In article <1992Jul18.214750.12347@mole-end> mat@mole-end writes:
  13. > |I beg to differ.  What _does_ seem to happen is that if you don't participate
  14. > |in the live discussions, you don't appreciate how much analysis is needed,
  15. > |or the problems of communicating with others present.  
  16.  
  17. > On the contrary, I haven't been there, yet I DO appreciate the problems.
  18.  
  19. > |If you haven't seen
  20. > |it happen, you just can't provide what's needed.  (So I testify, having been
  21. > |there.)
  22.  
  23. > As one WG member told me, "tough nuggets."  I can't be there, so this is
  24. > besides the point.  If committee members cannot communicate what's needed,
  25. > then they certainly cannot communicate what is required of C++ programmers
  26. > and C++ compiler implementors via a written document called a "standard."
  27. > If it is impossible for them to communicate via written form, such as by
  28. > letters or by email, then the issue of this written document called 
  29. > the "standard" is moot.
  30.  
  31. Ok.  Let's try some things on for size.  (I'm taking some text out of
  32. order here.)
  33.  
  34. > If some "analysis" of operator.() remains to be done, then how come neither
  35. > you nor any other committee member is willing to identify for me EXACTLY
  36. > WHAT issues remain to be addressed?  I submit on the contrary, if neither
  37. > you nor any other committee member is willing to identify to me EXACTLY
  38. > WHAT issues remain to be addressed, then there ARE NO such other issues
  39. > that remain unaddressed.
  40.  
  41. First, take some of Coplien's examples (or your own) and show how they
  42. would look if your version of  operator.()  is implemented.  Interlard
  43. the before and after in the paper.  Give consideration to interactions
  44. with other things (e.g. overloading and function signatures) because
  45. people _will_ want to use them together in expressions.
  46.  
  47. Second, gather up the miscellaneous issues that we've been kicking around
  48. on this newsgroup and incorporate them into the right places in the
  49. proposal.  Then let's you and me and a few others get together by email
  50. and work the proposal over end-to-end.
  51.  
  52. > BUT, I HAVE BEEN asking WG committee members of these "other" proposals
  53. > you mention for about the last year, and none have been willing to
  54. > send me a copy of these "other" proposals.  HOW can I address these
  55. > "phantom" proposals if no one will show them to me?
  56.  
  57. Let's get together on e-mail about these.  You'd be surprised what can
  58. be done on a small-circulation mailing list.  We have until very late
  59. fall; that's enough time if we start now.
  60.  
  61. > Then send me a copy of these alternative proposals, and I will write
  62. > up such a comparison from my point of view.  Even if you disagree with
  63. > my "analysis" I will take at least some of the burden off of you and
  64. > the other committee members.
  65.  
  66. Right now, none of them has much favor.
  67. -- 
  68.  (This man's opinions are his own.)
  69.  From mole-end                Mark Terribile
  70.  
  71.  uunet!mole-end!mat, Somewhere in Matawan, NJ
  72.