Re: Rational for not making cursor tagged in Containers

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

Anh Vo <anhvofrcaus@gmail.com> writes:

> On Apr 19, 11:25 am, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>>
>> I suppose it's because there's no need for type extension or dispatching
>> calls.  So why pay the overhead?
>
> Well, I have not yet come across the situation where a Container type
> needs to be extended. And yet, overhead was already paid.

True.

I think the rationale is that container types typically need
finalization, so they need to be derived from Controlled, so they are
tagged.  It was not necessary to make them VISIBLY tagged, but
I think the idea was "why not?".  You're paying for the tag
anyway, whether or not it's in the visible part.

That leads to the question, why can't we have untagged types with
finalization?  The answer is that during Ada 9X, the
derive-from-controlled idea was thought to be the simplest.
And finalization almost didn't make it into Ada 95.

>> A different question might be: Why is the prefix notation not allowed
>> for untagged types?  I don't know the answer to that, but it's probably
>> documented in the relevant AI.
>
> Then, it is not an extended (objectable) type. I will look for it.

And another question: why can't untagged types be extended?
That was allowed in the original design for Ada 9X.
Tags are needed for dispatching, but they are not needed
for extension.

>> I'm not a big fan of prefix notation, by the way.
>
> It is not uncommon that different people have different thinking. For
> me prefixed notation clearly has advantages. Of course, I like to use
> them to the fullest :-)

There is an advantage: If you have type P1.T1, with operation Mumble,
and P2.T2 extends P1.T1, and X is of type T2, do I say "P1.Mumble(X, ...)",
or "P2.Mumble(X, ...)"?  It's confusing, because it depends whether Mumble
is class-wide or dispatching, which is a conceptually minor
distinction.  And it's not unusual to change from dispatching
to class-wide.  The notation "X.Mumble(...)" avoids that confusion.

Nonetheless, it just seems weird to me to pretend that Mumble
is inside X, like a component.  There must be a better way.

- Bob