pattis@cs.washington.edu (Richard Pattis) (08/02/90)
What are the current restrictions placed on opaque types? In the old days, they could be any 1-word type (admittedly, a bit loosely defined). Then I heard the Standard said that they must be pointers. Here is my problem with that. Suppose I am implementing an ADT that includes the ability to store and retrieve values (think of a table). I would like to have cursors to the values stored in the ADT. I would like both the type of the ADT and the type of its cursors to be opaque. If I implement the ADT as a linked list, then both types would be pointers; if I implement the ADT as a pointer to an array, the types would be a pointer and an integer respectively. But if opaque types must be pointers, I must then implement the cursor type as a pointer to an integer, or play games with the type system. Any informed opinion out there about the Standard? About what the popular M-2 compilers say? Rich Pattis
lins@Apple.COM (Chuck Lins) (08/02/90)
In article <12695@june.cs.washington.edu> pattis@cs.washington.edu (Richard Pattis) writes: >What are the current restrictions placed on opaque types? In the old days, >they could be any 1-word type (admittedly, a bit loosely defined). Then I >heard the Standard said that they must be pointers. Here is my problem with >that. These days it seems that most (all?) compilers require the implementation of an opaque to be a pointer. For the sneaky, however, ADDRESS (a 4-byte quantity) is compatible. > >Suppose I am implementing an ADT that includes the ability to store and >retrieve values (think of a table). I would like to have cursors to the >values stored in the ADT. I would like both the type of the ADT and the >type of its cursors to be opaque. If I implement the ADT as a linked list, >then both types would be pointers; if I implement the ADT as a pointer to >an array, the types would be a pointer and an integer respectively. > >But if opaque types must be pointers, I must then implement the cursor type >as a pointer to an integer, or play games with the type system. > >Any informed opinion out there about the Standard? About what the popular >M-2 compilers say? > >Rich Pattis One question I would have is: Do you want your cursors to different ADTs to be compatible with one another? In other words, would a cursor for a linked list ADT be usable as a cursor for the array based ADT? If so, this complicates things quite a bit for the cursors. Assuming that a given cursor is bound to a specific instance of the ADT, you make things easier for yourself, by documenting the constraints that clients (users of the ADT) must follow. Thus, you can say 'Cursors created for use with a specific ADT are usable only with that ADT'. Let's get a specific example here (to make sure I'm being perfectly clear). DEFINITION MODULE MyADT; TYPE ADT; TYPE Cursor; (*-- operations on the ADT including creating a cursor for an instance, advancing the cursor, etc. *) END MyADT. IMPLEMENTATION MODULE MyADT; TYPE ADT = POINTER TO (* something specific here. list or array *) TYPE Cursor = SYSTEM.ADDRESS; (*-- the rest of the implementation *) END MyADT. Within the implementation, we know the structure of the ADT (pointer-based or array-based). In the list case, we 'know' that the cursor is a pointer to some element of the list. Conversely, in the array case, we 'know' that the cursor is an index into the array. Unfortunately, if the client module using ours doesn't follow the caveat(s), nasty things can occur (using an array based cursor in a listed based ADT, for example). Partly, it depends on who is the user. If it's yourself only, you can be certain that a disciplined, competent programmer is using the module. If not, perhaps for stringent measures are necessary to product the poor, little ADT module from harm. The other problem you may run encounter in the array based case is whether you want multiple cursors active per ADT. If so, a simple integer index won't do; you'll need a pointer to a structure containing the reference to the ADT and the current index. Well, I can see I've from far afield of your original question and so I'll shut up now :-) -- Chuck Lins | "Is this the kind of work you'd like to do?" Apple Computer, Inc. | -- Front 242 20525 Mariani Avenue | Internet: lins@apple.com Mail Stop 37-BD | AppleLink: LINS@applelink.apple.com Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set.