Re: 'with'ing and 'use'ing

[Robert Dewar <dewar@gnat.com>]

In article <89h5lh$70r$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> That's a very contraversial issue (odds are, you've just
unwittingly
> touched off another flamewar about it). Suffice it to say that
many
> people (myself included) think that's the "right" way to do
things. Many
> other people whose opinions I respect feel that's hogwash.


So, when you are using existing packages that are already
existing, the choice of whether to use USE or not is often
dictated by the naming conventions of that package. When you
design a package, you choose names that are designed either
with the idea of USE in mind or not.

It is really quite irritating to see a package that was
carefully designed to be used with USE adopted into a program
which blindly follows the no-USE policy, and end up with noise
like:

   Angle_Handling.Angle_Handling_Options := True;

As always, blind rules are just that, blind :-)

Whether it is a good idea or not to avoid USE depends on many
things, but the basic design point of view is to make things
easier for the reader. This may partially depend on the
environment. For example, if the readers have to suffer in
an environment (they still exist :-( today) where there is
no simple way to click on a name to immediately find out what
package it is defined in, then putting dots all over the place
may have some advantage in some cases for readers.

What some people like to do is to use local abbreviations

  package MCA renames Major_Complex_Arithmetic;

and then use MCA.xxx in the client. This to me seems the worst
of both worlds, because now even a complete familiarity with
the package is not enough to guess what is going on. If you
must follow this approach, please standardize the abbreviations
to be used and document them in the package itself, so that
all clients use the same abbreviation.

Indeed if everyone everywhere will use MCA as the "name" of
this package, perhaps you should define a library level
renaming of the package and with that, or even change the
name of the package to MCA.

My own taste is for a flexible approach. Use USE where it is
helpful to do so, don't use it otherwise, don't have fixed
rules (which are seldom a good substitute for judgment).

The policy in the GNAT sources is to use USE in the compiler
itself, it makes the code a lot clearer once you get to know
the basic structure of the sources, since in 99% of the cases
you immediately know where something is. For example, even a
surface familiarity of the GNAT sources will tell you that

  Expand_N_Goto_Statement;

must be in the package Exp_Ch5, since it is obviously an
expansion activity, and we know goto's are a statement form
defined in chapter 5. Furthermore, we assume that typically
if you are working with the GNAT sources, you have reasonable
locating tools available (such as are supplied with GNAT).

For the run-time library, we mostly avoid the use of USE, since
these sources are used in all kinds of contexts, and typically
and frequently examined by people not very familiar with the
library.

It is relatively unusual (did any user ever do it?) to dip into
the GNAT front end sources to answer a question about GNAT. It
is quite common to dip into the runtime for this purpose.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.