Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!warwick
From: warwick@batserver.cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.lang.modula2
Subject: Re: Standard Modula2
Message-ID: <7091@uqcspe.cs.uq.oz.au>
Date: 30 Jan 91 23:34:58 GMT
References: <1180.279FE75C@puddle.fidonet.org> <1991Jan25.174802.11700@m2xenix.psg.com> <1991Jan30.091656.4348@mack.uit.no>
Sender: news@uqcspe.cs.uq.oz.au
Reply-To: warwick@batserver.cs.uq.oz.au
Lines: 24

In <1991Jan30.091656.4348@mack.uit.no> torbjorn@forit.forut.no (Torbjorn Sund) writes:


>Jon.Guthrie@p15.f20.n226.z1.fidonet.org (Jon Guthrie) writes:
> 
>> All I want to do is be able to assign any quantity of type ADDRESS to an
>> opaque type.  I also want to be able to test an opaque type for equality to
>> NIL.
> 
>Who says that an opaque type is assignment or storage equivalent to ADDRESS?
>At least one compiler (FTL) did not impose the restriction that an
>opaque type be implemented as a pointer.

That's right, opaque is OPAQUE - It represents a level of abstraction,
which you cannot circumvent, you shouldn't really be using assignment
operations with an opaque type.  If you need some sort of ADDRESS from
the opaque type, then the module exporting the type should given you
a function to do that, if not, then you should make NO ASSUMPTIONS
about the opaque type.
--
________________________________________________________

	This .signature intentionally left blank
________________________________________________________