home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / modula2 / 1438 < prev    next >
Encoding:
Text File  |  1992-11-22  |  3.4 KB  |  66 lines
  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!swrinde!emory!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!news.belwue.de!theorie!titania.mathematik.uni-ulm.de!borchert
  3. From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
  4. Subject: Re: Oberon-2 discussion continues
  5. Message-ID: <1992Nov23.065513.5398@informatik.uni-ulm.de>
  6. Sender: usenet@informatik.uni-ulm.de (Name for nntp-posting)
  7. Nntp-Posting-Host: titania.mathematik.uni-ulm.de
  8. Organization: University of Ulm, SAI
  9. References: <9211130912.A01822@MAIL.CASI.NASA.GOV> <37695@uflorida.cis.ufl.edu>
  10. Date: Mon, 23 Nov 92 06:55:13 GMT
  11. Lines: 53
  12.  
  13. In article <37695@uflorida.cis.ufl.edu>, bmr@buoy.cis.ufl.edu (Benedict Rafanello) writes:
  14. > |> >>>  e) DEFINITION & IMPLEMENTATION merged.
  15. > 
  16. > |>  >>This was a really bad move.  Now you can't define the interface separately
  17. > |>  >>and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
  18. > |>  >>of Wirth's work.  Even if you accept that merging the def and imp is good,
  19. > |>  >>interface details like READONLY really deserve their own keywords.
  20. > 
  21. > |>  No, this is a good move.  The maintenance of only 1 file is a big
  22. > |>  win.  If you are concerned about the definition being published with
  23. > |>  the source, don't worry.  There is a `Browser' module which will
  24. > |>  output a definition for a compiled module.  You can then ship the
  25. > |>  defintion (sans comments, unless you provide them) with your object
  26. > |>  modules.
  27. > 
  28. > If both the interface and the implementation are in one file, how do you
  29. > tell when only the implementation was changed?  This is very important for
  30. > large projects.  Some of the projects that I have been involved with contain
  31. > more than a million lines of code.  These projects (done in Ada) would take
  32. > several DAYS just to compile.  If the interface to a package was changed,
  33. > we would have to go through that horrendous compile cycle whereas if just
  34. > the implementation was changed, we only needed to relink.  How does Oberon
  35. > handle this?
  36. > 
  37. > Ben
  38.  
  39. The Zurich Oberon compiler generates symbol files (interface definitions
  40. for the compiler itself) like Modula-2 compilers for definition modules.
  41. On compilation of a module, you may choose whether to recreate a
  42. symbol file or not. If you don't recreate the symbol file but the
  43. compiler detects differences between the new module and the old symbol
  44. file, you get some nice error messages.
  45.  
  46. This, of course, makes compiling more difficult: usually you are trying
  47. to compile without generating new symbol files. Only in case of error
  48. messages, to try to recompile it with the \s flag.
  49.  
  50. Until now, I haven't detected any sufficient support for something like
  51. make on UNIX-Systems, so it's a non-trivial task to compile greater
  52. stuff under the Oberon-System. Please tell me if this has been changed
  53. in the latest versions or if there is some work on this in progress.
  54.  
  55. Nevertheless, I still prefer the idea that I have a source file with
  56. a time stamp which represents the interface. That's good for my makefiles
  57. and my personal overview. A separately formatted and hand-written
  58. definition module is a document which cannot be replaced by the
  59. browser tool of the Zurich Oberon system.
  60.  
  61. -- 
  62. _______________________________________________________________________________
  63.  
  64. Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
  65. Internet: borchert@mathematik.uni-ulm.de
  66.