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=-0.9 required=5.0 tests=BAYES_00,YOU_INHERIT
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cb68a222818235ed
X-Google-Attributes: gid103376,public
Path: 
 g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Nick Roberts" <nick.roberts@acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Renaming of enumeration constant
Date: Thu, 10 Jun 2004 18:38:49 +0100
Message-ID: <2irkl9Fqi7qpU1@uni-berlin.de>
References: <ca9v8l$5gb8@cui1.lmms.lmco.com>
X-Trace: news.uni-berlin.de lNdNNnZixCeSry2jbSozaQjbDA6ozIvs1PvGB+X7UGNly7opg=
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Xref: g2news1.google.com comp.lang.ada:1377
Date: 2004-06-10T18:38:49+01:00
List-Id: <comp.lang.ada>

"Xenos" <dont.spam.me@spamhate.com> wrote in message
news:ca9v8l$5gb8@cui1.lmms.lmco.com...

> Just a curiosity question:
>
> What is the difference (advantages, etc.) of defining a function rename
for
> an enumeration constant over just creating a constant.  Consider:
>
> package X is
>   type E is (A, B, C);
> end X;
>
> with X;
> package Y is
>    function A return X.E renames X.A;
> end Y;
>
> with X;
> package Z is
>   A : constant X.E := X.A;
> end Z;
>
> Is the "A" in Y treated any different than the "A" in Z by the compiler,
or
> will both achieve the same results.  Is one considered "better" (whatever
> that means) than the other?

I think the answer to your question is actually about inheritance.

Suppose we have the following packages:

   package Farm is
      type Leggedness is (Four_Legs, Two_Legs);
      Bipedal: constant Leggedness := Two_Legs;
      function Quadrupedal return Leggedness renames Four_Legs;
      ...
   end;

   with Farm;
   package Zoo is
      type Podality is new Farm.Leggedness;
      ...
   end;

In this situation, there will be an inherited operation:

   function Quadrupedal return Podality renames Four_Legs;

in which the Four_Legs value it returns is of the type Podality. This
operation is inherited, because it is a primitive operation of the type
Leggedness (it is declared directly in the same package specification). In
fact, this is why we get the names Four_Legs and Two_Legs for values of the
type Podality: they are functions, and they are primitive operations, so
they are inherited.

The constant Bipedal, however, is not inherited.

My own opinion is that constants are silly in Ada, but they were introduced
in Ada 83 (and its predecessors), long before the question of inheritance
was understood to be important. The advantage that constants have is that
their declaration is simpler and perhaps more obvious, and it doesn't matter
if they do not need to be inherited.

I sometimes wish to derive a type from
Ada.Strings.Unbounded.Unbounded_String, and I am annoyed that I have to
redeclare the constant Null_Unbounded_String (because it is not inherited).
It gives me the opportunity to play with names:

   type Teacher_Name is new Ada.Strings.Unbounded.Unbounded_String;

   Null_Teacher_Name: constant Teacher_Name :=
      Teacher_Name(Ada.Strings.Unbounded.Null_Unbounded_String);

but inheritance doesn't usually prevent the introduction of new names (as
renamings of functions or procedures).

For interest, compare the following possible alternative package
specifications for Zoo:

   with Farm;
   package Zoo is
      subtype Podality is Farm.Leggedness;
      ...
   end;

In this example, Podality is declared simply as a subtype of Farm.Leggedness
(without reducing the set of values). This is really just a way of renaming
a (sub)type. Since Zoo.Podality and Farm.Leggedness are of the same type, no
conversion is required between values of either subtype.

   with Farm;
   package Zoo is
      type Podality is range 0..100;
      function To_Leggedness (B: Podality) return Farm.Leggedness;
      function To_Podality (L: Farm.Leggedness) return Podality;
      ...
      Invalid_Legs: exception;
   end;

Here we declare a new type Podality altogether (which can cope with
centipedes and fish), and provide functions to convert to and from
Farm.Leggedness. The function To_Leggedness raises the exception
Invalid_Legs if B is neither 2 nor 4.

HTH

-- 
Nick Roberts