Re: Rationale

[leschkes@ferret.cig.mot.com (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