From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,856114749978634c
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Protected Types and Address Clauses
Date: 1996/02/23
Message-ID: <Dn8uEM.4B8@world.std.com>#1/1
X-Deja-AN: 140843601
references: <4gcppr$10f5@watnews1.watson.ibm.com> <dewar.824905563@schonberg>
 <Dn5Mq1.Ewz@thomsoft.com> <4gi71p$94s@wdl1.wdl.loral.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-02-23T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <4gi71p$94s@wdl1.wdl.loral.com>,
Mark A Biggar <mab@dst17.wdl.loral.com> wrote:
>That's not a work around, it is the necessity and proper implementation
>method in almost all cases.

I agree it's not a workaround.  It's perfectly reasonable to use
protected objects to protect stuff that's not inside the protected
object.  This case (with the address clause) is one case where it
really can't be inside.  There are other cases.

I'm not sure what you mean by "in almost all cases".  I think it's
*usually* best to put the stuff being protected inside the protected
object.  I guess you mean, "in almost all cases where the thing being
protected needs to be located at a particular address".

One useful technique (probably not applicable in this case, but in
others) is to have a component of the protected object be a pointer to
the stuff being protected.  For example, the PO can have an access
discriminant:

    type Stuff is ...
    
    protected type P(S: access Stuff) is ...
    
    X: Stuff;
    
    PO1: P(S => X'Access); -- protect a pre-existing thing
    
    PO2: P(S => new Stuff'(...));

- Bob