home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!think.com!spool.mu.edu!tulane!uflorida!buoy.cis.ufl.edu!bmr
- From: bmr@buoy.cis.ufl.edu (Benedict Rafanello)
- Newsgroups: comp.lang.modula2
- Subject: Re: Oberon-2 discussion continues
- Message-ID: <37695@uflorida.cis.ufl.edu>
- Date: 21 Nov 92 23:39:59 GMT
- References: <9211130912.A01822@MAIL.CASI.NASA.GOV>
- Sender: news@uflorida.cis.ufl.edu
- Organization: Univ. of Florida CIS Dept.
- Lines: 24
- Nntp-Posting-Host: buoy.cis.ufl.edu
-
- |> >>> e) DEFINITION & IMPLEMENTATION merged.
-
- |> >>This was a really bad move. Now you can't define the interface separately
- |> >>and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
- |> >>of Wirth's work. Even if you accept that merging the def and imp is good,
- |> >>interface details like READONLY really deserve their own keywords.
-
- |> No, this is a good move. The maintenance of only 1 file is a big
- |> win. If you are concerned about the definition being published with
- |> the source, don't worry. There is a `Browser' module which will
- |> output a definition for a compiled module. You can then ship the
- |> defintion (sans comments, unless you provide them) with your object
- |> modules.
-
- If both the interface and the implementation are in one file, how do you
- tell when only the implementation was changed? This is very important for
- large projects. Some of the projects that I have been involved with contain
- more than a million lines of code. These projects (done in Ada) would take
- several DAYS just to compile. If the interface to a package was changed,
- we would have to go through that horrendous compile cycle whereas if just
- the implementation was changed, we only needed to relink. How does Oberon
- handle this?
-
- Ben
-