Re: Records that could be arrays

[Stephen Leake <stephe_on_the_web@toadmail.com>]

Wilhelm Spickermann <zhopi.20.unbenutzbar@spamgourmet.com> writes:

> This becomes also visible in the missing loop statements in
> typical polar coordinate operations. And it would be rather
> unusual for an array to have a special equality definition 

Perhaps it is "unusual" in your experience because you are overly
restrictive in using arrays for such types.

Having said that, I don't think I've ever overridden equality for an
array. But I rarely override equality for any type, so that's not a
good measure.

> while it is rather normal for a record (phi is "dont care" when
> theta is zero -- or AFAIK the other way round in North America).

Right. So if we are using an array to represet these coordinates, we
would override equality for that type.

Ada lets us do that, so there is (by definition :) nothing "wrong"
with it!

Equal rights for arrays :).

I see this as similar to a discussion of implementation for a
container. At a high level, we don't care whether a "set" is implemented
as an array of bits or a list of some sort. At a lower level, we do,
and we ask "what is the implementation that gives the fastest
execution time" or similar questions.

At a high level, a "point" is an abstract object, and we don't care
about the representation. At the low level, we ask "would it ever be
convenient to use a loop to process the elements of this type". If the
answer is 'yes', we use an array.

What I have been saying is that the answer is almost always 'yes',
when you consider operations like Text_IO and AUnit checks.

If we implemented points as limited private types, we wouldn't be
having this discussion. But writing access functions instead of just
using Ada syntax is "obviously" too heavy for points, so we make them
public types. But the priciple still applies; the implementation of
the type is logically separate from the abstract interface of the type.

-- 
-- Stephe