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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ada-uts.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ada-uts!stt
From: stt@ada-uts.UUCP
Newsgroups: net.lang.ada
Subject: Re: Orphaned Response
Message-ID: <4700016@ada-uts.UUCP>
Date: Mon, 20-Jan-86 12:47:00 EST
Article-I.D.: ada-uts.4700016
Posted: Mon Jan 20 12:47:00 1986
Date-Received: Thu, 23-Jan-86 21:05:26 EST
References: <4700013@ada-uts.UUCP>
Nf-ID: #R:ada-uts:4700013:ada-uts:4700016:177600:733
Nf-From: ada-uts!stt    Jan 20 12:47:00 1986
List-Id: <comp.lang.ada>


I am not sure I understand your point completely, but
I certainly agree that "use" visibility is bad news in
a large system.  I would prefer "use" visibility to
go away completely.   The presence of a feature like
"defining-package" visibility would make it largely unnecessary.
Unfortunately, upward compatibility requires that it be left in the
language, though perhaps it could be marked for eventual removal.

The advantage of "defining-package" visibility is that
the code-reader only need be aware of the package(s) defining
the types in the expression, rather than all possibly "used"
packages.  It also encourages the "abstract" type
approach, where the defining package provides the whole
story w.r.t. a type.
 -Tucker Taft