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,63a41ccea0fc803a
X-Google-Attributes: gid103376,public
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Naming of Tagged Types and Associated Packages
Date: 1998/08/31
Message-ID: <m3d89iqtfd.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 386276739
Sender: matt@mheaney.ni.net
References: <m3af5jm7fy.fsf@mheaney.ni.net>
 <Ex9unC.43p.0.-s@inmet.camb.inmet.com>
NNTP-Posting-Date: Sun, 30 Aug 1998 17:13:39 PDT
Newsgroups: comp.lang.ada
Date: 1998-08-31T00:00:00+00:00
List-Id: <comp.lang.ada>

stt@houdini.camb.inmet.com (Tucker Taft) writes:

> We have been quite happy for the past 15 years (and > 1M SLOC)
> using the with/rename approach, exemplified by:
> 
> with Ada.Strings.Bounded;
>   ...
>     package ASB renames Ada.Strings.Bounded;
>   ...
> 
>     X : ASB.Bounded_String;
> 
>   ...
> 
>     if ASB.Length(X) = 0 then ...

I find this style a bit old-fashioned.  

First of all, you don't need to tell me every time you invoke an
operation on X that the operation is defined in package ASB.  I already
know that, because you said so in the declaration.  So why tell me
again, and again, and again...?

Of course, you might be using a non-primitive operation defined in some
package other than ASB.  If the operation is defined in a non-obvious
place, then perhaps it does make sense to use an expanded name.

But, if the defining packages are carefully named, then that gives you a
strong clue that that's where an operation or type is coming from.  For
example, if I see the declaration

   X : Bounded_String;
...

then I'm going to look at the context clause for a package named
Bounded_Strings.  The ASB part (or even a fully expanded name) is
largely redundant.

If the operation is non-primitive (meaning I didn't find it in the
package that declared the type), then I'd look for some other clue about
its origin.  For example, if I saw this

   Some_Weird_Operation (X);

then I'd look for a package called Bounded_String_Utilities, or
something like that.

Of course, if the (non-primitive) operation is not declared in an
obvious place, then it is wise for the writer to give the reader a hint
as to it's origin, perhaps using the expanded name notation technique
you mention.

Remember, types and operations usually go together.  Tell me where one
is, and that's usually where I'll find the other too.

> This makes it very easy to follow all references, without 
> overwhelming the user with repetitive, long-winded package
> names everywhere.  All of the package renames are at the
> beginning of the compilation unit containing the references.
> Ideally, the abbreviations are agreed-upon on a project-wide basis.

My personal experience is that abbreviations of this kind are usually
unreadable.  If a shop is really allergic to use clauses in the context
clause, then I prefer this sort of thing:

with Ada.Strings.Bounded_Strings;
...

   X : Ada.Strings.Bounded_Strings.Bounded_String;

   use Ada.Strings.Bounded_Strings;
begin
   if Length (X) = 0 then ...;

The idea is to use fully qualified types in the object declaration,
followed by a use clause just prior to the end of the declarative
region.

A compromise position is:

with Ada.Strings.Bounded_Strings;  use Ada.Strings;

That way I only have to specify the most deeply-nested package in a
declaration:

   X : Bounded_Strings.Bounded_String;

   use Bounded_Strings;
begin


But you see even from the example above that expanded name
Bounded_Strings.Bounded_String is a bit redundant.  If I have a type
named Bounded_String in a scope, from what package other then
Bounded_Strings can it come from?