comp.lang.ada
 help / color / mirror / Atom feed
From: "Samuel T. Harris" <sam_harris@hso.link.com>
Subject: Re: One type for all
Date: 1999/07/09
Date: 1999-07-09T00:00:00+00:00	[thread overview]
Message-ID: <3786741C.E73F1124@hso.link.com> (raw)
In-Reply-To: 3783E0D2.5D74243@boeing.com

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




  parent reply	other threads:[~1999-07-09  0:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3783E0D2.5D74243@boeing.com>
1999-07-08  0:00 ` One type for all czgrr
1999-07-09  0:00 ` Samuel T. Harris [this message]
1999-07-10  0:00   ` Ehud Lamm
1999-07-12  0:00     ` Samuel T. Harris
1999-07-12  0:00   ` Robert Dewar
1999-07-12  0:00     ` Samuel T. Harris
1999-07-12  0:00     ` Larry Kilgallen
1999-07-17  0:00       ` Robert Dewar
1999-07-18  0:00         ` Samuel T. Harris
1999-07-18  0:00         ` Keith Thompson
1999-07-19  0:00           ` Robert Dewar
1999-07-18  0:00             ` Keith Thompson
1999-07-19  0:00             ` Robert A Duff
1999-07-20  0:00               ` Robert Dewar
1999-07-19  0:00             ` Tucker Taft
1999-07-20  0:00             ` Bill Findlay
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox