Re: Renaming of enumeration constant

["Xenos" <dont.spam.me@spamhate.com>]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:2irkl9Fqi7qpU1@uni-berlin.de...

> 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
>
>

Thanks for taking the time to writing this.  I found it VERY informative.

DrX