Re: Ada name space (was: Re: good software engineering)

Re: Ada name space (was: Re: good software engineering)

[Robert Dewar]

One of the problems in choosing names for Ada packages that are to be shared
is that the naming style that one wants is indeed very different depending
on whether or not you expect to use qualification.

The most sensible thing would be for each portable package to simply specify
whether or not it was intended to be used with "use" clauses or not.

The trouble is that if you design a package with names chosen to be appropriate
if the package is used, then when people import it into an environment where,
for whatever reasons, the use of use is restricted, they end up with horrible
names.

One can of course decide that all portable packages should have names designed
for fully qualified use, but you have to remember that a lot of Ada programmers
prefer *not* to use fully qualified names all the time.

I don't intend to start a futile flame war as to whether one should or not
make use of use clauses, or insist on full qualification. This has been 
discussed to death. The bottom line is that there are really two schools
of thought, and the real world contains people with both points of view
(I dislike the fully qualified style, but I quite understand that there
are many Ada programmers who prefer it, and I am not about to argue that
they should change -- anti-use people should show the same curtesy in the
other direction!)

So we are left with trying to compromise between the two viewpoints. Certainly
I think most people dislike thinks like:

	Posix.Posix_Exceptions



Robert Dewar

Re: Ada name space (was: Re: good software engineering)

[agate!howland.reston.ans.net!europa.eng.gtefsd.com!fs7.ece.cmu.edu!news.s]

In article <dewar.739044733@schonberg> dewar@schonberg.NYU.EDU (Robert Dewar) w
rites:

>So we are left with trying to compromise between the two viewpoints. Certainly
>I think most people dislike thinks like:
>
>	Posix.Posix_Exceptions

I confess I see no good reason to compromise, and one good reason not
to: any compromise will satisfy neither party and yield a product whose
nomenclature is confusing and inconsistent.

Make a choice and stick to it.  The Ada 'renames' facility is there
precisely so as to provide relief for users who find that choice hard
to live with.

Re: Ada name space (was: Re: good software engineering)

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!noc.near.net]

In article <dewar.739044733@schonberg> dewar@schonberg.NYU.EDU (Robert Dewar) 
writes:

>One of the problems in choosing names for Ada packages that are to be shared
>is that the naming style that one wants is indeed very different depending
>on whether or not you expect to use qualification.

In article <1993Jun3.080544.29388@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth)
writes:

>I confess I see no good reason to compromise, and one good reason not
>to: any compromise will satisfy neither party and yield a product whose
>nomenclature is confusing and inconsistent.
>
>Make a choice and stick to it.  The Ada 'renames' facility is there
>precisely so as to provide relief for users who find that choice hard
>to live with.

Another related name-space problem arises if one wants to include, in the
names of library units, some reference to the static hierarchy.  For
example, one may require that the name of every unit begin with a two or
three-letter abbreviation of the CSC in which that unit belongs.  This has
certain advantages, among them:  one may more easily manipulate the source
code files of all the units in a CSC as a group; one is given some
contextual information about a unit given only its name; and this helps to
reduce the probability of discovering, during integration, that two units
have the same name.  However, this practise does not make it easier to come
up with natural-sounding names.  (It also does not make reuse easier, but
that's a separate issue.)

One solution that I've used is to rename a with'd library unit with either
a shorter, descriptive name or an abbreviation.  I only do this in the
body of the withing unit in order to avoid declaring a new visible reference to
the with'd unit.  That is, I would not do the following:

   with A_Long_And_Painfully_Descriptive_Name;
   package B is
      package A renames A_Long_And_Painfully_Descriptive_Name;
      procedure P( O : in out A.Data_Type );
   end B;

because any unit that with's B can then reference A without withing it.

Paul Slonaker
Intermetrics, Inc.

Re: Ada name space (was: Re: good software engineering)

[David Emery]

A "trick" that I saw in the old AIE code was to define a standard
abbreviation for long package names:

	package LONG_AND_VERBOSE_DESCRIPTIVE_NAME is
    	  -- abbreviation: LVD_NAME
	...
	end LONG_AND_VERBOSE_DESCRIPTIVE_NAME;

then the abbreviation is used in a renames clause:

	with LONG_AND_VERBOSE_DESCRIPTIVE_NAME;
	procedure USER is
	   package LVD_NAME renames LONG_AND_VERBOSE_DESCRIPTIVE_NAME;
	...
	end USER;

The "bonus" from this system was that the filename was the same as the
abbreviation, so you'd have something like:

	lvd_name.spec
	lvd_name.body

So the abbreviations were 'standard' and people came to know and love
them, while the original long/descriptive names were still preserved,
and of course if you forgot what LVD_NAME is short for, you just have
to search for the renames clause.

				dave