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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!husc6!harvard!panda!genrad!decvax!wanginst!vilot
From: vilot@wanginst.UUCP (Michael Vilot)
Newsgroups: net.lang.ada
Subject: Re: Preferred style of use-clauses
Message-ID: <169@wanginst.UUCP>
Date: Wed, 13-Aug-86 17:11:30 EDT
Article-I.D.: wanginst.169
Posted: Wed Aug 13 17:11:30 1986
Date-Received: Thu, 14-Aug-86 08:28:46 EDT
References: <860802130119.442853@MIT-MULTICS.ARPA> <8608041746.AA00283@jade.SPP.TRW> <2938@sdcrdcf.UUCP>
Reply-To: vilot@wanginst.UUCP (Michael Vilot)
Organization: Wang Institute, Tyngsboro, Ma.  01879
Keywords: use clause
List-Id: <comp.lang.ada>

In article <2938@sdcrdcf.UUCP> lwall@sdcrdcf.UUCP (Larry Wall) writes:
>
>If you are in a situation where the types of your subprogram arguments are
>clear, and your abstract types are all nicely confined to packages so that
>you don't rely on hiding mechanisms of dubious value, I see no reason to
>avoid the use of multiple USE clauses, even in large projects, even where
>it results in overloading.  

Consider  one more reason to  have USE  clauses:  changing a package's
imported environment  explicitly.  Suppose   you  have  built a   test
version of a system which instruments some features you are interested
in.  Now,  suppose you have  to get the  same  system into "production
shape" (i.e. faster and/or smaller), and you're not  interested in the
instrumentation.  It may be far easier to go from:

with Heavily_Instrumented_Package; use Heavily_Instrumented_Package;
procedure The_System is
begin
	Do_Interesting_Stuff;
end;

	... to:

with Simpler_and_Faster_Package; use Simpler_and_Faster_Package;
procedure The_System is
begin
	Do_Interesting_Stuff;
end;

	... than to replace all occurrences of the fully qualified
names.

	Of course, in a well-run project, the need for two versions is
all seen in advance, and the change should "never be needed" :-)