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.7 required=5.0 tests=BAYES_00,HK_RANDOM_FROM, MSGID_RANDY 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: czgrr Subject: Re: One type for all Date: 1999/07/08 Message-ID: <7m1io9$3db$1@nnrp1.deja.com> X-Deja-AN: 498450838 References: <3783E0D2.5D74243@boeing.com> X-Http-Proxy: 1.0 x43.deja.com:80 (Squid/1.1.22) for client 193.192.234.4 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Jul 08 07:07:57 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) Date: 1999-07-08T00:00:00+00:00 List-Id: In article <3783E0D2.5D74243@boeing.com>, Robert Jordan wrote: > This one's got me wondering if I missed a change between Ada83 and > Ada95: I'll say now that I don't know Ada95, but do use Ada83. I'll leave any Ada95-specific comments to others. I'll also say that I have not compiled and tested the code I give here, it's just to show the concepts. So please excuse any typos or other blatantly silly mistakes. (; > 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? [snip] > type int32 is range -32000..32000; > type command_list is > record > Command1: int32; > Command2: int32; > end record; [snip] > 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; By defition of the language, int32 and integer_32_type are *different* types. Okay, they inherit operators, etc from universal_integer, since you are effectively saying... type integer_32_type is new Universal_Integer range -32000..32000; Note the "new". This means you can't directly interchange them. That's the whole point of using strong typing; int32 and integer_32_type could represent completely different kinds of data, the compiler doesn't know you want them to be the same. For example... type month is range 1..12; type am_pm_hour is range 1..12; type times_tables is range 1..12; -- at least it was in my day! Does assignment between these make any sense? You could have... subtype integer_32_type is parser.int32; > > 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. You could also try the following... type integer_32_type renames parser.int32; type Command_Code_Record_Type renames parser.command_list; although in the case of the latter you would change field names Command_01 and Command_02, which might affect your code if you have used named notation, for example. But later, you can have something like... Command_01 : integer_32_type renames Command_Code_Record_Type.Command_01; or something like that, anyway, I haven't tried it. I prefer the suggestion below in a situation like this. > 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 Another possible answer to this is to use a wrapper around parser. To continue your example, you would have something like... package parser_wrapper is -- Procedures and functions which mimic those in the spec of -- parser, but use the other types instead. procedure get_record(out the_record : Command_Code_Record_Type); end package; ----- with parser; package body parser_wrapper is function convert(in parser_data : parser.int32) return integer_32_type is begin -- Base types can be type-cast directly. return integer_32_type(parser_data); end convert; function convert(in parser_data : parser.command_list) return Command_Code_Record_Type is begin -- Record types must be built from their components. -- Same for any other complex structure. return ( Command_01 => convert(parser_data.Command1, Command_02 => convert(parser_data.Command2); end convert; -- Provide convert's to and from each parser type and its -- external equivalent. procedure get_record(out the_record : Command_Code_Record_Type) is parser_the_record : parser.command_list; begin -- Procedures and functions call the parser version with any -- IN parameters convert'ed beforehand, and OUT parameters -- convert'ed afterwards. For IN OUT, use a combination. parser.get_record(parser_the_record); the_record := convert(parser_the_record); end get_record; end parser_wrapper; > 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). Then perhaps the parser package should have been written as a generic! > > 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. Oh yes, I forgot to say... If you use the parser_wrapper package, you have to WITH that *instead of* the parser package. Your code above would become... My_Commands : Command_Code_Record_Type; --Already existing code parser_wrapper.get_record(My_Commands); --Desired new action If you use the renames, you have to repeat them every time or put them in a separate package and WITH (and USE?) that everywhere you want access to your types. Comments on my suggestions, additional suggestions, plus Ada95-specific solutions, anyone? HTH czgrr -- No email, please - reply to the newsgroup. My opinions are not necessarily those of my employer. Use any suggestions at your own risk. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.