home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / eiffel / 1320 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.1 KB  |  64 lines
  1. Newsgroups: comp.lang.eiffel
  2. Path: sparky!uunet!mcsun!Germany.EU.net!rrz.uni-koeln.de!unidui!math.fu-berlin.de!Sirius.dfn.de!th-ilmenau.RZ.TH-Ilmenau.DE!PrakInf.TH-Ilmenau.DE!huebner
  3. From: huebner@PrakInf.TH-Ilmenau.DE (Huebner)
  4. Subject: "Rename" considered hazardous
  5. Message-ID: <1992Nov23.135527.7035@th-ilmenau.RZ.TH-Ilmenau.DE>
  6. Sender: news@th-ilmenau.RZ.TH-Ilmenau.DE (Newsserver)
  7. Nntp-Posting-Host: saturn.prakinf.th-ilmenau.de
  8. Organization: Technische Hochschule Ilmenau
  9. Date: Mon, 23 Nov 92 13:55:27 GMT
  10. Lines: 52
  11.  
  12.  
  13. Handling the problem of name conflicts arising from multiple inheritance 
  14. by renaming could be a nice solution. But it seems that there should be
  15. some restrictions to ensure the reliability of the produced software.
  16.  
  17. By abuse of the renaming mechanism there could the following situation
  18. become reality:
  19.  
  20. class A                class B
  21. export f, ...            export h, ...
  22. feature             inherit
  23.   f: integer is             A rename f as h
  24.     -- "meaning of 'f'"        feature    
  25.     do ... end;               -- no declaration of f
  26. end                end
  27.  
  28. and anywhere out there is an innocent class C, that believes, that all
  29. objects of Typ A (or of one of its subtypes) understand the message "f",
  30. maybe class B is really created after C.
  31.  
  32. class C
  33. export foo, ...
  34. feature
  35.   foo(arg: A): integer is
  36.     -- "meaning of function 'foo'"
  37.     do
  38.       Result := arg.f * 10
  39.     end:
  40.  
  41. Another innocent (who is innocent?) person wants to use the classes A, B
  42. and C. SHe only knows and believes in the class interfaces and refuses to 
  43. learn anything about the implementation details of A, B and C.
  44.  So sHe writes:
  45.  
  46.     x: A;
  47.     y: B;
  48.     z: C;
  49.     x.Create; y.Create;
  50.     ...
  51.     z.foo(x);   -- o.k.
  52.     z.foo(y);   -- Error: message "f" not understood by object of Typ B
  53.  
  54. Who is the bad boy?   -  I think it's class B.
  55.  There should be a function f in class B according to the pre-post-conditions 
  56. (and the "meaning" explained) in class A.
  57. But that forbids the use of rename for cosmetical purposes ("name polishing")
  58. and requires a more restricted and supervised use of 'rename'.
  59. I think the example "repeated inheritance and renaming" from ambuj@ucsb.edu
  60. shows the problems of tricksy programming, enabled by 'rename'.
  61.  
  62. Michael H"ubner, TU Ilmenau
  63.  
  64.