home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!comp.vuw.ac.nz!waikato.ac.nz!ldo
- From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
- Newsgroups: comp.sys.mac.programmer
- Subject: Re: Think Pascal - Whats... - data abstraction?
- Message-ID: <1992Nov18.172004.12287@waikato.ac.nz>
- Date: 18 Nov 92 17:20:04 +1300
- References: <6746@m1.cs.man.ac.uk> <1351@my.sm.luth.se>
- Organization: University of Waikato, Hamilton, New Zealand
- Lines: 32
-
- In article <1351@my.sm.luth.se>, matti@my.sm.luth.se (Matti Larborn) writes:
- >
- > Another question: Why don't Think Pascal support abstract datatypes?
- >
- > The only thing they would have to add is an export declaration:
- >
- > x=object
- > export a,b; { or name it public if you like }
- > a: integer;
- > b: real;
- > c: char; { hidden }
- >
- > {?operations }
- > end;
-
- Why bother? There are too many potential complications with this scheme:
-
- * What if you want the user to be able to read, but not write those fields?
- * What if you want the user to be able to write those fields in a certain
- restricted fashion to preserve certain relationships to the values in
- other fields?
- * What if you later decide not to store that field, but compute it from
- some other fields? Changing this would break existing clients.
-
- A simpler and more general approach is to define accessor procedures and
- functions. These can enforce any constraints you like. And they don't need
- a new language feature!
-
- Lawrence D'Oliveiro fone: +64-7-856-2889
- Computer Services Dept fax: +64-7-838-4066
- University of Waikato electric mail: ldo@waikato.ac.nz
- Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
-