Re: Exchanging objects between programs with different inheritance hierarchies

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

Steven Deller wrote:

> My question is, what this a reliable, portable way to do that transfer.
> The "solution" should only involve reasoning from the Ada RM, not any
> detailed knowledge of any compiler, including GNAT.


One problem is that the RM does not specify what a tag is.
One compiler may implement tags as a string while another uses
a numeric value.


> 
> I believe streams and 'Class'Output and 'Class'Input may be the answer,
> but find myself unable to fully understand the RM's "contract" with
> regard to writing, and then reading, tagged type objects.


You will need to provide a common package on both systems.
That package should define the tagged types and also a customization of
the 'Class'Input and 'Class'Output operations. Without a common
package between the systems you do not have common types. Remember that
a type's name includes its package name.


> 
> I assume 'Class'Input will correctly work when the same *process*
> performed the 'Class'Output.
> 
> What about the same *program* running as one *process* doing the
> 'Class'Output and as another *process* of the same program doing the
> 'Class'Input? (That is, is an Ada compiler allowed to build tag
> information at elaboration time, with possible variations from run to
> run?)


This is very simple. There should be no surprises with this arrangement.


> 
> What about different programs, but with the identical inheritance
> hierarchy for the types in question? (There might be other differing
> type hierarchies, but not for the types being transmitted.)
> 
> Finally, the 64K question.  What if the inheritance hierarchies differ,
> but transmission is limited to types that have the identical inheritance
> "path" within the hierarchy?


As long as the types are constructed from common packages you should
have no problems. You cannot read a type for which your program has
no definition. Without a definition the tag cannot be recognized,
and resulting dispatching operations cannot be located and executed.


> 

> One last question, which does not affect this particular effort, but
> could affect future work.  What if the inheritance hierarchies are
> identical in structure, but not in the particular names used for the
> various types and components.  Is there anything in 'Class'Output/Input
> that would permit exchanging those structurally-equivalent and
> inheritance-equivalent types?


You need to share the same packages on both sides of an 'Input / 'Output
stream communication. Types defined in two different packages are not
the same type.

Jim Rogers