Re: Access type to member procedure of instance (Object Oriented programming in Ada)

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1ilx4ms9xk5h8.pz5jsnqrogye.dlg@40tude.net...
...
>No idea. It is a great mystery to me what makes into the language and what
>does not. Considering this one:

Obviously, you can read the AIs and the meeting minutes to find out why 
things were done the way they are. That's one reason that the associated AIs 
are linked in the AARM for every changed paragraph.

> 1. Why closures at all?

I assume we're talking about Ada's "prefixed views" (closures are something 
else to me). A combination of popular demand and the fact that Ada 83 
already had them for tasks.

> 2. Why some arguments are more important than others, unless the 
> programmer
> specifies so?

No good reason, IMHO, other than that that was the way it worked for tasks 
in Ada 83.

> 3. Why closures must support only tagged types?

We tried to allow prefixed views for all types, but we ran into problems 
because Ada always allows an implicit conversion at a dot, and we didn't 
want these to be different. In the end, we decided on restricting it to just 
tagged types because the rules worked well with them. Almost all new types 
ought to be tagged (and controlled) anyway [yes, I realize that some 
language rules don't allow that in some cases - grumble].

One advantage of restricting prefixed views to tagged types is that it 
leaves the door open for future extensions to other kinds of types. If we 
allowed it on other kinds of types and got it wrong, we'd be stuck with it 
forever (compatibility concerns would not allow us to change the meaning in 
the future). And we certainly were not sure how the rules should work for 
untagged types. So this is a case where doing nothing was better than doing 
something we were not sure about.

                                                  Randy.