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

  1. Newsgroups: comp.lang.c++
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Path: sparky!uunet!pipex!demon!trmphrst.demon.co.uk!nikki
  4. Distribution: world
  5. Subject: inherited:: proposal (Was: Renew?)
  6. References: <1992Jul28.184049.24609@ucc.su.OZ.AU>
  7. X-Mailer: cppnews $Revision: 1.10 $
  8. Organization: Trumphurst Ltd.
  9. Lines: 56
  10. Date: Fri, 31 Jul 1992 10:47:49 +0000
  11. Message-ID: <712604869snx@trmphrst.demon.co.uk>
  12. Sender: usenet@gate.demon.co.uk
  13.  
  14.  
  15. In article <1992Jul28.184049.24609@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  16. >     Hope Bjarne doesnt mind me posting this.
  17. ..
  18. > From bs@research.att.com Tue May 19 04:13:57 1992
  19. ..
  20. > This paper proposes the extension of C++   with the  keyword
  21. > inherited,  a  qualified-class-name used to denote an inher-
  22. > ited class member.  The advantages are a clearer inheritance
  23. > relationship  and  increased programming safety.  The imple-
  24. > mentation cost is small, and the consequences  for  existing
  25. > code minor.
  26. ..
  27. > We will
  28. > never know if  this  proposal  would  have  passed,  though,
  29. > because  at  this  point  in the discussion, Michael Tiemann
  30. > walked in and muttered something like ``but  we  don't  need
  31. > that extension; we can write code like that already.''  When
  32. > the murmur of ``but of course  we  can't!''  had  died  down
  33. > Michael showed us how:
  34. > 9     class foreman : public employee {
  35. >          typedef employee inherited;
  36. >          // ...
  37. >          void print();
  38. >      };
  39. > 99     class manager : public foreman {
  40. >          typedef foreman inherited;
  41. >          // ...
  42. >          void print();
  43. >      };
  44. > 99     void manager::print()
  45. >      {
  46. >          inherited::print();
  47. >          // ...
  48. >      }
  49. > What we hadn't  noticed  was
  50. > that  the  re-introduction  of  nested  classes into C++ had
  51. > opened the possibility of controlling the scope and  resolu-
  52. > tion of type names exactly like other names.
  53. I found this example very illuminating (not surprising, considering its 
  54. source :-). I might well start using "inherited" typedefs in my user
  55. interface toolkit (although I might call it "base" or "super" instead of
  56. "inherited" - comments anyone ?). 
  57.  
  58. I would be interested to learn about other proposals which have been 
  59. rejected, particularly those for which the main reason for rejection was 
  60. that existing language features made the proposal unnecessary. I feel I 
  61. could broaden the scope of my C++ knowledge considerably this way.
  62.  
  63. Is there anywhere where I could obtain access to such information ?
  64. ---
  65. Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
  66. Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
  67. PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
  68. trmphrst.demon.co.uk is NOT connected with ANY other sites at demon.co.uk.
  69. Demon.co.uk is a dial-up subscription access point to the Internet.
  70.