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,9d0b383ee17c13af
X-Google-Attributes: gid103376,public
From: "Samuel T. Harris" <sam_harris@hso.link.com>
Subject: Re: One type for all
Date: 1999/07/09
Message-ID: <3786741C.E73F1124@hso.link.com>#1/1
X-Deja-AN: 499268030
Content-Transfer-Encoding: 7bit
References: <3783E0D2.5D74243@boeing.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: Raytheon Training Inc.
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-07-09T00:00:00+00:00
List-Id: <comp.lang.ada>

Types in both Ada 83 and Ada 95 use name-equivalence instead
of structural-equivalence (as is found in Pascal). The fact
that the type have the same structure and bounds is not
relevant. Because the type have distinct declarations is
all that matters. One type is Command.Int32 and the other
is Some_Package.Integer_32_Type. You have two separate and
distinct types. If you want the type to be interchangeble,
then use subtypes, although many will reason (and rightly so)
that subtypes across packages exposes one to a host of
problems since the strong-typing features of Ada are being
by-passed.

Robert Jordan wrote:
> 
> This one's got me wondering if I missed a change between Ada83 and
> Ada95:
> 
> If I had one package that did something interestingly useful:  Say, it
> parsed command lines or so... That I didn't write but wanted to use as a
> component of a larger system.
> 
> If the larger system maintained a duplicate set of types that the parser
> used (Possibly using different names), how could I instruct the compiler
> to treat one type as an equivilant to another without having to modify
> the parser spec or body?
> 
> For example,
> 
> In the parser, there are two types defined:
> 
> type int32 is range -32000..32000;
> type command_list is
> record
>    Command1: int32;
>    Command2: int32;
> end record;
> 
> and in the bigger SW, in which I wish to insert the handy parser there
> are types already defined as:
> 
> type integer_32_type is range -32000..32000;
> type Command_Code_Record_Type is
> record
>    Command_01: integer_32_type;
>    Command_02: integer_32_type;
> end record;
> 
> I would like to be able to
> 
> with parser;
> 
> in the larger application but use the already existing application
> Command_Code_Record_Type to reference parameters and such from the
> parser which uses command_list without having to equate each instance of
> the records.
> 
> Common Ada doesn't seem to allow me to do the following:
> 
> in parser:
> 
> procedure get_record(out the_record : command_list) ;
> 
> and in the application, I'd like to do this:
> 
> My_Commands : Command_Code_Record_Type;   --Already existing code
> parser.get_record(My_Commands);           --Desired new action
> 
> It seems to me that if a package is to be truely encapsulated, one
> shouldn't have to depend on the names of the types in that package so
> long as the data formats line up exactly.  Of course, this kind of
> action may not be desireable in all circumstances, but it does appear
> that Ada acts this way when dealing with standard scalar types
> (Standard.Integer and such).
> 
> It also seems non-OO to have to 'with' the parser spec into the bigger
> application at the expense of the types already defined in the
> applications spec when the two are exactly the same.
> 
> Any insight would be appreciated.
> 
> Thanks,
> Robert Jordan

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"