home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16425 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.7 KB  |  71 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
  3. From: sakkinen@jyu.fi (Markku Sakkinen)
  4. Subject: Re: Member function renaming proposal from the ARM
  5. Message-ID: <1992Nov17.103735.23693@jyu.fi>
  6. Organization: University of Jyvaskyla, Finland
  7. References: <721945900snx@trmphrst.demon.co.uk>
  8. Date: Tue, 17 Nov 1992 10:37:35 GMT
  9. Lines: 60
  10.  
  11. In article <721945900snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
  12. >I have a question about an extension to the language to allow programmers 
  13. >to specify inheriting and optionally renaming functions. The extension is 
  14. >proposed in the ARM 10.11c (pp 236-237). 
  15. >
  16. >Let us assume two base classes with name clashes ...
  17. > ...
  18. >// The suggested extension would allow ...
  19. >class LotterySimulation : public Lottery, public GraphicalObject {
  20. >    // ...
  21. >    virtual int l_draw() = Lottery::draw;
  22. >    virtual void draw() = GraphicalObject::draw;
  23. >    };
  24. >
  25. >It is stated in the ARM that such a language extension is not _necessary_,
  26. >and is only worthwhile if the need to resolve such name clashes proves 
  27. >common. It strikes me that the workround suggested in the ARM is going to 
  28. >cause some loss of efficiency on most compilers around today.
  29.  
  30. I will take some ideas from my paper in Computing Systems
  31. (A critique of the inheritance principles of C++) -- excuse the plug.
  32. The ARM is actually wrong:  some extension like this would be necessary
  33. in order to _redefine_ the two 'draw' functions separately.
  34. At least Eiffel has the 'rename' clause for this purpose.
  35.  
  36. >I see another use for this extension (see ARM also 13.1 pp310-312) ...
  37. > ...
  38. >class Derived {
  39.               ^^ : public Base  (obviously)
  40. >public:
  41. >    // ...
  42. >    void set(int) = Base::set(int);
  43. >    void set(double) = Base::set(double);
  44. >    virtual void set(char *s);
  45. >    };
  46. >
  47. >This will prevent set(int) and set(double) being hidden by set(char *), 
  48. >without any loss of efficiency in the calling mechanism.
  49. > ...
  50.  
  51. I suggested an even more convenient way for inhibiting the obnoxious
  52. hiding rule in the paper:
  53.     reveal set;
  54. I.e., none of the overloaded 'set' functions would be hidden.
  55. Even better if the hiding would not be the default, but could
  56. be effected when desired by
  57.     hide set;
  58.  
  59. In both cases, I think that conceptual clarity is a stronger argument
  60. than efficiency for the proposed language modifications.
  61.  
  62. ----------------------------------------------------------------------
  63. Markku Sakkinen (sakkinen@jytko.jyu.fi)
  64.        SAKKINEN@FINJYU.bitnet (alternative network address)
  65. Department of Computer Science and Information Systems
  66. University of Jyvaskyla (a's with umlauts)
  67. PL 35
  68. SF-40351 Jyvaskyla (umlauts again)
  69. Finland
  70. ----------------------------------------------------------------------
  71.