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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1826acc50ed3055b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-23 08:27:37 PST Path: nntp.gmd.de!newsserver.jvnc.net!nntpserver.pppl.gov!princeton!udel!news.sprintlink.net!howland.reston.ans.net!math.ohio-state.edu!news.acns.nwu.edu!ftpbox!mothost!delphinium.cig.mot.com!ferret!leschkes From: leschkes@ferret.cig.mot.com (Scott Leschke) Newsgroups: comp.lang.ada Subject: Re: Rationale Date: 23 Jan 95 16:27:37 GMT Organization: Motorola Cellular Infrastructure Group Message-ID: References: NNTP-Posting-Host: ferret.rtsg.mot.com Date: 1995-01-23T16:27:37+00:00 List-Id: 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@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