[net.lang.ada] Preferred style of use-clauses

Bakin@MIT-MULTICS.ARPA ("David S. Bakin") (08/02/86)

Can anyone tell me which of the following two styles is preferred,
or how they differ, or even just which YOU prefer?  (If you prefer
NOT to use use-clauses you could let me know if you wish, but tell
me why.)  I'll summarize for the net.  THANKS  -- Dave Bakin
(Bakin -at mit-multics.arpa)

Style 1:

    with this;
     use this;
    with that;
     use that;
    {package/procedure/function} interesting is
     ...
    begin
     ...
    end;

Style 2:

    with this;
    with that;
    {package/procedure/function} interesting is
       use this;
       use that;
       ...
    begin
       ...
    end;

alden%jade@spp1.UUCP (08/05/86)

	Unless this and that are text_io, the solution is simple ---
	Don't use "use"

	... Tony

P.S.

	If you really must use "use", I suggest you limit the scope of the
use by putting it only in the block that needs to have it.  When you put the
use in a block (procedure, package body or spec, function, block, etc.), you
limit the damage use can do to just that scope.  

lwall@sdcrdcf.UUCP (Larry Wall) (08/06/86)

Have you guys actually been burned by USE clauses, or are you just afraid of
the dark?

I can only see two situations where a USE clause might hurt you:

1) If you USE two packages with homographic subprograms, you could end up
relying on overloading.  This cannot get you the wrong subprogram unless
you make an *explicit* type error.  You cannot get the wrong subprogram
by specifying the type insufficiently--this will only result in ambiguity,
which results in an illegal call, caught at compile time (6.6-3).

2) You CAN get the wrong subprogram by the hiding mechanism.  Consider the
following:

	with FOO;
	procedure BAR is
	    procedure X is ... end X;
	    procedure SUBBAR is
		use FOO;	-- FOO declares procedure X also
	    begin
		X;		-- this is BAR.X, not FOO.X
	    end SUBBAR;
	end BAR;

The hiding occurs because directly visible declarations hide within their
immediate scope anything that would be made visible by a USE clause (8.4-5).
It seems to me that mistaking BAR.X for FOO.X is more likely because the USE
clause is so much closer than the declaration of the directly visible BAR.X.
In this case, putting the USE up with the WITH might be less confusing,
especially to someone reading the program backwards to find the declaration
of X.

Neither of these problems is a strong argument against using USE clauses.
#1 is more of an argument against overloading.  #2 is an argument against
nesting procedures too deeply.

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.  In particular, the use of overloaded operators
in infix notation pretty requires either a USE clause or a slough of RENAMESes.

My rule of thumb would be this: only use USE over large scopes, where the
package used is well known, and can be borne in mind as part of the global
context.  In narrow scopes I'd tend to use RENAMES instead, to avoid problems
with hiding.

How's that for being contrary?

Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall

vilot@wanginst.UUCP (Michael Vilot) (08/14/86)

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" :-)