Comments on the Rationale

[R_Tim_Coslet@cup.portal.com]

This posting is a summary of an E-mail exchange I had with
dewar@GNAT.CS.NYU.EDU (Robert Dewar) a couple days ago about
the Rationale and a confusion I had over dispatching.


The code examples given in the Rationale all seem to be written
in a coding style with use clauses and positional association
of operands. But many coding standards (and my personal preference)
require named association of operands and discourage use clauses.

Given the example in I-2.3 of the Rationale as a reference,
it was unclear how one would write a dispatching call on the
Alert'Class to the procedure Handle. It was unclear to me
whether Normal_Alert_System.Handle(...) or Base_Alert_System.Handle(...)
should be called and which names should/could be used for the
named association (e.g. Handle for Alert uses the name "A", for
Low_Alert uses the name "LA", etc.).

If I understand Robert's explanation correctly, then the Base_Alert_System
package when it declares:

	procedure Handle(A: in out Alert) is abstract;

is also implicitly declaring a classwide Handle procedure something
like this (but dispatching):

	procedure Handle(A: in out Alert'Class);

Therefore a dispatching call using the Alert system in I-2.3 would
be written as follows:

	Base_Alert_System.Handle(A => Some_Classwide_Alert_Variable);

Correct? Any comments?


Even ONE example of this in the Rationale using this coding style would
have helped considerably in avoiding this confusion.


BTW, can this implicitly declared procedure be renamed?
Something like:

	procedure DH(A: in out Alert'Class) renames
		Base_Alert_System.Handle;

It seems to me that an explicitly declared procedure like that would
be non-dispatching... (if I read things correctly)




I think my original confusion was that I was thinking of dispatching
as a kind of "runtime" overload resolution... which, now that I think
about it, simply doesn't make sense... But in Ada83 overload resolution
was the closest thing there was to any kind of "semi-polymorphic"
behavior in the language :-)

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena