home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16047 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  2.7 KB
  1. Xref: sparky comp.lang.c++:16047 comp.std.c++:1528
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!taumet!steve
  4. From: steve@taumet.com (Steve Clamage)
  5. Subject: Re: PROPOSAL: Hidden private parts of classes
  6. Message-ID: <1992Nov10.191740.2438@taumet.com>
  7. Organization: TauMetric Corporation
  8. References: <1992Oct30.113234.15010@daimi.aau.dk> <1992Nov7.154137.21910@ucc.su.OZ.AU> <1992Nov9.032225.10320@taumet.com> <1992Nov10.071110.6177@jyu.fi>
  9. Date: Tue, 10 Nov 1992 19:17:40 GMT
  10. Lines: 46
  11.  
  12. sakkinen@jyu.fi (Markku Sakkinen) writes:
  13.  
  14. >In article <1992Nov9.032225.10320@taumet.com> steve@taumet.com (Steve Clamage) writes:
  15. >>If you mean private non-virtual member functions which don't appear in
  16. >>the class definition, it would cause another language change.
  17. >>Overloading is resolved before accessibility is checked.  Suppose we have:
  18. >> ...  Overloading
  19. >>is resolved first precisely to avoid quiet semantic changes based only
  20. >>on access rights.
  21.  
  22. >In my opinion, it was a bad choice in the first place to resolve
  23. >overloading before accessibility, although the argument presented in the ARM
  24. >makes partial sense.  However, that argument does not apply at all
  25. >to this new suggestion:  since such helper functions were to be declared
  26. >outside the class definitions, they cannot be made accessible to derived
  27. >classes or outside cliennt just by changing access rights.
  28.  
  29. I neglected to carry my discussion to the next logical step.
  30.  
  31. The class could have different semantics depending on which declarations
  32. were visible in which compilation units.  This is just what is being
  33. asked for, but IMHO you should not want this facility; it is a
  34. recipe for subtle bugs.
  35.  
  36. At the time you set up the class and provided some hidden functions
  37. you had some reason for wanting to do so.  Maybe you even documented
  38. it in a comment somewhere.  What about the next programmer doing
  39. maintenance (which could be you 6 months later)?  Just what are the
  40. slippery semantics of the class supposed to be?
  41.  
  42. Clients using the class expect precisely the visible semantics.  Some
  43. impelemtation details depend on bent semantics.  When some of these
  44. details need to be modified, which version of bent semantics should
  45. be used?  What if the maintainer doesn't notice extra functions which
  46. affect overloading but which are not visible in the class definition
  47. and documentation?
  48.  
  49. Some languages (Modula, Ada) provide for completely hidden
  50. implementation details.  This is a nice feature overall, but is
  51. controlled in these languages.  I don't believe such languages
  52. allow completely free and ad-hoc declarations, and it seems to
  53. me that is what is being proposed here.
  54. -- 
  55.  
  56. Steve Clamage, TauMetric Corp, steve@taumet.com
  57. Vice Chair, ANSI C++ Committee, X3J16
  58.