home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / eiffel / 1022 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.7 KB  |  95 lines
  1. Path: sparky!uunet!mcsun!uknet!mucs!cs.man.ac.uk!mod
  2. From: mod@cs.man.ac.uk (Michael O'Docherty (CAG ra))
  3. Newsgroups: comp.lang.eiffel
  4. Subject: Type hole in Eiffel
  5. Message-ID: <mod.712424989@cs.man.ac.uk>
  6. Date: 29 Jul 92 15:49:49 GMT
  7. Sender: news@cs.man.ac.uk
  8. Lines: 85
  9.  
  10. Please consider the following system of classes, which runs up against
  11. a type hole in Eiffel 2.3:
  12.  
  13. ---------------------------------------------
  14. class CELL[T]
  15. export
  16.         item, put
  17. feature
  18.         item:T;
  19.  
  20.         put (v:like item) is
  21.                 do
  22.                         item := v
  23.                 end;
  24.  
  25. end
  26. ---------------------------------------------
  27. class PARENT
  28. feature
  29. end
  30. ---------------------------------------------
  31. class CHILD
  32. export
  33.     child_routine
  34. inherit
  35.     PARENT
  36. feature
  37.     child_routine is
  38.         do
  39.         end;
  40. end
  41. ---------------------------------------------
  42. class SILLY
  43. feature
  44.     fill_with_parent(p_cell:CELL[PARENT]) is
  45.         local
  46.             p:PARENT;
  47.         do
  48.             p.Create;
  49.             p_cell.put(p);
  50.         end;
  51.  
  52.     Create is
  53.         local
  54.             c_cell:CELL[CHILD];
  55.         do
  56.             c_cell.Create;
  57.             fill_with_parent(c_cell);
  58.             c_cell.item.child_routine;
  59.         end;
  60. end
  61. ---------------------------------------------
  62.  
  63. The problem stems from the fact that CELL[CHILD] conforms to
  64. CELL[PARENT]. If you follow through the Create procedure of SILLY
  65. you'll see that `child_proc' is called on an object whose dynamic type
  66. is PARENT. This causes 2.3 to seg-fault at run time. I tried a similar
  67. but more convoluted example of this on EIffel/S for the PC (note that
  68. this is 3.0) and the error was *caught* at run time and a message
  69. issued along the lines of ``feature not on object''.
  70.  
  71. I know this is probably an old and very well known hole, (I believe
  72. it's the second one outlined in ``A Proposal for Making Eiffel
  73. Type-Safe'', W.R. Cook, Computer Journal, August 1989). However, there
  74. are a few questions which I have difficulty finding answers to in the
  75. FAQ and the Eiffel 3.0 book (either because I'm missing something or
  76. because they're not there ;^) :
  77.  
  78.  (1) Are all the classes class-valid?
  79.  (2) Is the system system-valid?
  80.  (3) Is this hole caught by ISE Eiffel 3.0 (salivates uncontollably),
  81.         and if so is it caught at compile time or run time?
  82.  (4) Alternatively to (3), have the conformance rules been changed to
  83.         ban this situation?
  84.  (5) Does ISE Eiffel 3.0 enforce every aspect of system and class
  85.         validity (and if so, at run time or compile time)?
  86.  (7) Any other questions I haven't thought of?
  87.  (6) Is that enough questions?
  88.  
  89.  
  90. Any attempts to answer any or all of these questions greatly appreciated.
  91.  
  92. Mike.
  93.  
  94. Internet: mod@cs.man.ac.uk, wet string: (+44) 061 223 1301 ext. 2343
  95.