home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11299 < prev    next >
Encoding:
Text File  |  1992-07-21  |  2.6 KB  |  57 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!uunet.ca!canrem!telly!moore!torsqnt!lethe!comspec!scocan!paul
  3. From: paul@sco.COM (Paul Jackson)
  4. Subject: Re: Committee Members -> What do you think?
  5. Organization: SCO Canada, Inc.
  6. Date: Mon, 20 Jul 1992 15:03:41 GMT
  7. Message-ID: <1992Jul20.150341.5723@sco.COM>
  8. References: <1992Jul13.172044.5706@microsoft.com> <1992Jul15.144839.18494@sco.COM> <1992Jul17.194202.14981@microsoft.com>
  9. Sender: news@sco.COM (News administration)
  10. Lines: 45
  11.  
  12. In article <1992Jul17.194202.14981@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  13. >Your definition of what a "standard" "is" flies in the face of the reality
  14. >of the ANSI-C++ committees actions.
  15.  
  16. The committee does have the mandate to fix "clear" deficiencies in the
  17. language. Most people feel that this included templates and exception
  18. handling. Many people feel that it includes little else. 
  19.  
  20. >|Getting back to operator dot, it may or may not make it into this (or any
  21. >|future) standard. If "almost everybody" implements it, or "almost everybody"
  22. >|demands it or "almost everybody" agrees that it is a good idea then it will
  23. >|"almost certainly" make it in. If not, the chances are lower.
  24. >
  25. >On the contrary "almost everybody" will have no say in this matter, as
  26. >history has already shown.  On the contrary, a couple people on the 
  27. >extensions committee will either support the idea, or talk it down, and
  28. >that will be sufficient to get it on, or keep it off, the floor of the
  29. >committee whole for a vote.
  30.  
  31. Oh, baloney. I assure you that of all the customers of vendor X's compiler
  32. clamour for operator dot then vendor X WILL put it into their compiler.
  33. Vendor X is then likely to try and get it into the standard. Or, if you
  34. convince 50% + 1 of the committee members then it will go in (note that
  35. Bjarne doesn't have to be convinced, he doesn't even get a vote).
  36.  
  37. >|Personally, I feel that it is just not too important an issue one way or
  38. >|another
  39. >
  40. >Operator.() is only necessary if one is interested in having complete
  41. >and safe "smart pointer", "smart reference", "smart array", "reference
  42. >counting" classes etc.
  43.  
  44. Convince me that it is NECESSARY and I'll recommend that my companies rep
  45. vote for it. By necessary, I mean that you CANNOT implement "smart" classes
  46. without it.
  47.  
  48. >This issue has been discussed dozens of times before.  OPERATOR.() IS NOT
  49. >A LANGUAGE EXTENSION -- IT IS A LANGUAGE REDUCTION -- IT IS A REMOVAL OF
  50. >AN ERRONEOUS AND UNNECESSARY PIECE OF SPECIAL CASE LANGUAGE IN THE SPEC.
  51.  
  52. Wrong. It changes the existing language and hence is, by the definition
  53. being used by the committee, an extension. All Humpty Dumpty arguments
  54. to the contrary don't impress me.
  55.  
  56.  
  57.