dalal@topaz.rutgers.edu (Mukesh Dalal) (09/05/87)
Assume that a module M1 exports a pointer type P opaquely, and a
module M2 imports P from M1 and declares a variable p of type P.
Can M2 refer to p^, new(p) and dispose(p) {allocate, or deallocate}?
i.e.,
DEFINITION M1;
TYPE P;
....
IMPLEMENTATION M2;
FROM M1 IMPORT P;
VAR p:P;
....
BEGIN
new(p);
....(p^);
...
Thanks in advance for the response.
--
Mukesh Dalal Voice: (201)-878-1763
Dept. of Computer Sc. (Rutgers) Net: dalal@topaz.rutgers.eduHABERNOL@DB0TUI11.BITNET (Thomas Habernoll) (09/06/87)
>Assume that a module M1 exports a pointer type P opaquely, and a >module M2 imports P from M1 and declares a variable p of type P. >Can M2 refer to p^, new(p) and dispose(p) {allocate, or deallocate}? How could you know anything about the implementation of an opaque type? What lets you believe that it has to be a pointer type? (Yes, I know there is a proposal to restrict opaque types to pointer types only. But (1) this doesn't change the meaning of the word "opaque" and (2) it is a proposal and current implementations don't have this restriction). Thomas
hiebeler@csv.rpi.edu (David Hiebeler) (09/08/87)
DEC's Modula-2 compiler will not dereference an opaquely declared pointer
from within an external module. (NEW() gives me a wrong parm type,
^ gives me dereference of a non-pointer). This seems logical; if the
type is opaquely defined, then one shouldn't be poking around with its
innards from another module. That's what transparent types are for.
If you wanted something which was opaque, but still allowed you to
perform those few actions, I suppose you could just export a couple of
procedures from the first module, which were simply calls to the system-
allocations procedures.
-D.H.
----
David Hiebeler hiebeler@csv.rpi.edu
Troy, NY "Illusions, Richard! Every
bit of it illusions!"sullivan@marge.math.binghamton.edu (fred sullivan) (09/09/87)
In article <14474@topaz.rutgers.edu> dalal@topaz.rutgers.edu (Mukesh Dalal) writes: > >Assume that a module M1 exports a pointer type P opaquely, and a >module M2 imports P from M1 and declares a variable p of type P. >Can M2 refer to p^, new(p) and dispose(p) {allocate, or deallocate}? > I certainly hope not. The implementations I've tried don't allow it. The point of opaque types is to hide the type of a data structure from modules which use it, allowing client modules to be independent of the particular implementation chosen. Thus clients modules can be written before, or concurrently with, the implementation module, and if one decides to change the implementation, then the client module doesn't have to be rewritten. This means that some method for initializing a variable of an opaque type must be provided (as a procedure). I tell my data structures students to expect to include an initialize procedure with every opaque type. Example: consider two implementations of linear lists. 1. a list is stored as a record where one field is the length and the other field is an array which holds the list elements. In this case, initialization consists of allocating the record and setting the size field to zero. 2. a list is stored as a linked list of nodes, each of which is a record, where one field holds an element and the other field holds a link to the next node. In this case initialization consists of setting the variable to NIL. If you write an initialize procedure, you can write client modules independently of the method used. If you want to be able to refer to p^, etc, then declare the type in the definition module, and don't make it an opaque type. I think that the statement "opaque type = abstract data type" in modula is a reasonable assessment of the situation. In fact, it is for this reason that we use modula to teach abstract data types in our data structures course. Fred Sullivan Department of Mathematical Sciences State University of New York at Binghamton Binghamton, New York 13903 Email: sullivan@marge.math.binghamton.edu