Re: Preferred style of use-clauses

[lwall@sdcrdcf.UUCP (Larry Wall)]

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