From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3dbf2f325f33ce35
X-Google-Attributes: gid103376,public
From: jerry@jvdsys.stuyts.nl
Subject: Re: Elimination of "use" clauses
Date: 1999/07/20
Message-ID: <FF61Lr.6A@stuyts.nl>#1/1
X-Deja-AN: 503154753
Sender: jerry@stuyts.nl (Jerry van Dijk)
References: <377B5807.88B875E0@cs.york.ac.uk> <7lh74s$v36$1@nnrp1.deja.com>
  <7ligdq$c8q$1@nnrp1.deja.com> <7ljb4e$na9$1@nnrp1.deja.com>
  <7ltus1$ah1@dfw-ixnews19.ix.netcom.com> <wccr9mc5y47.fsf@world.std.com>
 <7mrjus$bet@dfw-ixnews14.ix.netcom.com> <FF2ECA.76@stuyts.nl>
 <7n0hr7$180@dfw-ixnews21.ix.netcom.com>
Organization: * JerryWare HQ *, Leiden, Holland
User-Agent: tin/pre-1.4-980226 (UNIX) (Linux/2.2.10 (i586))
Newsgroups: comp.lang.ada
Date: 1999-07-20T00:00:00+00:00
List-Id: <comp.lang.ada>

Richard D Riehle <laoXhai@ix.netcom.com> wrote:

:>I am unfamiliar with the term 'opaque type', perhaps because I never looked
:>at Modula-3. Can you explain what it means ?

: An "opaque type" is a type in which all the details of the type are
: encapsulated in an implementation part of a module.  This is required
: in Modula-3.  Ada allows us to promote some of the definition to the
: private part of the specification.   Ada also allows us to defer the
: details to the pacakge body. 

: In this example, the private part contains all the information about 
: the structure of the stack.  The second Ada example is designed as an 
: "opaque type".  

Aha, yes I can see where the term comes from. Although I didn't know it,
I have been a heavy user of opaque types in cases where I wanted to hide
as much as possible of the actual implementation of the type from the user.

Actually, I thought of this of two styles of programming:

a) use the package body for only the implementation (i.e. functions and
   procedures), keep every else as much as possible in the spec. This
   keeps the body concentrated on the implementation, without being
   'distracted' by a lot of deferred definition. Advantages are, IHMO,
   easier testing. easier finding definitions. It also seems to be in
   the Ada spirit.
   
However, I sometimes feel unconfortable with this approach, switching to
the other style (where Ada allows it):

b) use the spec for exporting only information that the client program
   needs, moving as much as possible to the package body. The advantage
   is a better encapsulation (hmmm, ok, information hiding). Also usually
   less inpact when changing some small details.

As an old dutch proverb says: 'being consistent is develish', I tend to
use both styles. Style b) for things like a File_IO package that has to
run on both NT and Linux: single spec, multiple bodies. Style a) for database
implementations as these are not directly used by the client of the
database package itself.

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk