Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> That seems likely to create program-portability problems - on a 64-bit
> machine, a 64-bit record could be opaque, but it could not be opaque on
> a 32-bit machine (unless all pointers are artificially made 64 bits
> wide, too).

Yes.  I was appalled by that feature for exactly that reason.
I'm a big fan of portability.

But given the time frame of Modula-2, I think your example should be
16-bit/32-bit not 32/64.  ;-)

In any case, in plain English, "opaque" doesn't have all these
pointer/heap implications, so I suggest saying something like
"Modula-2-style opaque types" rather than just "opaque types"
if that's what you mean.

> The main difference is that in Ada, the unknown underlying type is named
> -- what you call the stt-incomplete type. This type is of course
> invisible to the users (clients) of the private type. Off hand, it does
> not seem to me that such named-but-incomplete types should cause hard
> problems for the compiler, but it appears that you have experienced such
> problems. Perhaps they did not exist in Ada 83, but came about because
> of other extensions such as controlled types?

The implementation problems existed in Ada 83.  I'm not sure I remember
all the issues, but the most obvious is that there's an implicit
assumption that you can tell the size/representation of a pointer
without knowing what it points at.  There are various reasons that might
not be true.  In fact, it's not true in GNAT.

Also, I think it was legal to do "X.all" on those things (in the package
spec) in Ada 83.  It would always raise Constraint_Error, but the
"natural" implementation wants to know the size of X.all.  I fixed that
in Ada 95 by changing the freezing rules to make it illegal, IIRC.

- Bob