Rationale

Rationale

[Scott Leschke]

Anybody know when the final version of the Rationale is to be completed ?
Has it been ?  I'm dying to find out why protected types are always limited
as opposed to being limited only when they have limited components as I
had expected.

Scott Leschke
Motorola Inc.
-- 
Scott Leschke

Re: Rationale

[Scott Leschke]

Well, actually the pass-by-copy aspect of the problem I thought of.  What
I guess I meant was, "Why not allow assignment and make the access trick
implicit unless explicitly disallowed by a component of the protected type
being limited."

In retrospect, it was kind of a stupid question since I know that this kind
of implicit pointer stuff was thought about and decided against for many
good reasons.

Scott Leschke


eachus@spectre.mitre.org (Robert I. Eachus) writes:

>In article <leschkes.790470294@ferret> leschkes@ferret.cig.mot.com (Scott Leschke) writes:

> > Anybody know when the final version of the Rationale is to be completed ?
> > Has it been ?  I'm dying to find out why protected types are always limited
> > as opposed to being limited only when they have limited components as I
> > had expected.

>      I would have thought that this was obvious.  What is the meaning
>(or usefulness) of an atomic operation whose parameters are passed by
>copy?  Or of an atomic update to a (temporary) copy of of an object?
>If a protected type was not limited, assignment would be defined for
>the type and all sorts of silliness would follow.

>      If you need to pass protected things around, follow the normal
>Ada rule and make the visible object type an access type.  That way
>you guarantee that updates to copies of the same object are
>serialized. Although, since Ada doesn't prevent changes to the access
>value, so be careful to always use the local copy of the access value.

>     Interesting, and cute trick...  Make the visible type a
>controlled type (with an access component), and use the intialize,
>adjust, and finalize operations to insure that assignments are
>serialized correctly IF the access value is non-null before or after
>the assignment.

>--

>					Robert I. Eachus

>with Standard_Disclaimer;
>use  Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
-- 
Scott Leschke

Comments on the Rationale

[R_Tim_Coslet]

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