Re: One type for all

[czgrr <czgrr@my-deja.com>]

In article <3783E0D2.5D74243@boeing.com>,
  Robert Jordan <robert.l.jordan@boeing.com> 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.