Version 1.1 of acs/ac-00009.txt

Unformatted version of acs/ac-00009.txt version 1.1
Other versions for file acs/ac-00009.txt

!standard 4.6 (00)          01-06-01 AC95-00009/01
!class uninteresting 01-06-01
!status received 01-05-17
!subject Dynamic view conversion
!summary
!appendix

!topic Dynamic view conversion
!reference RM95-4.6
!from Michael Gray
!sent Thursday, May 17, 2001, 7:23 AM
!discussion

We had a problem in comparing two tagged records A and B, where the type of
B is an extension of the type of A, and the type of A is an extension of
some Root_Type.

In a general piece of code (i.e. a piece of code written without knowledge
of which descendants of Root_Type exist), we needed to compare the values of
A and B, where the required semantics were to compare the common fields,
i.e. to check whether the fields of A had identical values in B. Although
this seems like quite a reasonable thing to want to do, it seems to be
impossible within the language.

I.e. consider

procedure X (A, B : in Root_Type'Class)
...
  if A = B ...

always delivers false if A and B are of different types.

The problem here is that there is no syntax that allows an object (B) to be
view-converted to the type of another object (A). Something along the lines
of A'Class(B) would be needed. This would then allow a comparison A =
A'Class(B). This would make inherited operations far more useful. In other
words, allow a view conversion where the target view is dynamically
determined rather than statically.

In implementations terms (I guess), to execute the required comparison, it's
'just' necessary to look up the address of the = operation in the dispatch
table (indexed via the tag of A), and to execute it, passing the objects A
and B as parameters .... ?

****************************************************************

From: Pascal Leroy
Sent: Monday, May 28, 2001 5:25 AM

I'd say that we don't want to add more dynamicity in the language at this stage.
My gut feeling is that defining the proposed construct would be quite hard, and
would probably have a significant impact on implementations.

But more importantly, conversions never change the tag of an object (RM95
3.9(25)) so I don't see how the proposed construct would help: in the comparison
A = A'Class (B), the tags would still be different, and the comparison would
still return False.

Note that while it is possible to write value conversions for tagged types (RM95
4.6(5/1)) the above rule presumably applies to both view conversions and value
conversions.

I have occasionally wanted a conversion-that-changes-the-tag, but not often
enough that I see this as an important addition to the language.  Incidentally,
if such a conversion existed I believe that it could be used to solve your
problem (in conjunction with clever use of dispatching subprograms).

****************************************************************

From: Christop Grein
Sent: Tuesday, May 29, 2001 5:22 AM

> > I.e. consider
> >
> > procedure X (A, B : in Root_Type'Class)
> > ...
> >   if A = B ...
> >
> > always delivers false if A and B are of different types.
> >

I've also once come into a situation where I wanted to compare the common parts
of tagged types, i.e. I would have needed an operation that, given two objects
of a class, returned the type of the first common ancestor, which you then could
use in a type conversion.

Something like

T'Common_Ancestor (A, B)
     converts A (the first argument) to that type which is the nearest
     common ancestor (going backward) of A and B in the hierachy T
     (for A, B in T).

There must always be a common root (it might however be abstract and this could
present a problem):

              Root
             /    \
            T1     T2
            /\     /\
         T11 T12 T21 T22

A: T11;
B: T12;
Root'Common_Ancestor (A, B) would convert A to T1

A: T11;
B: T2;
Root'Common_Ancestor (A, B) would convert A to Root

Thus one could write

  Compare (Left  => Root'Common_Ancestor (A, B),
           Right => Root'Common_Ancestor (B, A))

where Compare is a dispatching operation. [Problem when the common ancestor is
abstract and no operation exists => Constraint_Error, Program_Error ?]

I have no idea whether and how this could be implemented. I'm even not sure
whether such an operation really could make sense in general. The more I think
about it, the more it seems to be a burden for implementors.

So I returned to plain discriminated records.

****************************************************************

From: Michael Gray
Sent: Thursday, May 31, 2001 10:53 AM


> I'd say that we don't want to add more dynamicity in the language at this
> stage. My gut feeling is that defining the proposed construct would
> be quite hard, and would probably have a significant impact on
> implementations.

Fair enough. This problem hasn't cropped up for us very frequently; the
email from Christoph Grein ("I've also once come into a situation where I
wanted to compare the common parts of tagged types, ... " also implies that
it's an occasional problem rather than a recurrent one.

****************************************************************


Questions? Ask the ACAA Technical Agent