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,d1df6bc3799debed
X-Google-Attributes: gid103376,public
From: Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU>
Subject: Re: Not intended for use in medical,
Date: 1997/05/21
Message-ID: <5luq6m$svr$1@goanna.cs.rmit.edu.au>#1/1
X-Deja-AN: 242895645
Distribution: world
References: <3374C19F.15FE@sprintmail.com> <33828299.2A3@world.std.com>
 <mheaney-ya023680002005972249330001@news.ni.net>
X-XXMessage-ID: <AFA929D62E011B17@obibicut.cs.rmit.edu.au>
Organization: Royal Melbourne Institute of Technology
Newsgroups: comp.lang.ada
Date: 1997-05-21T00:00:00+00:00
List-Id: <comp.lang.ada>


Matthew Heaney= writes:

"That way I could say [about selectors]
 
 The_Stack.Top := 5;
 
 instead of
 
 Update_Top (The_Stack, To => 5);
 
 The idea is to let the compiler do the automatic defereferencing (a
 selector "invokation" could be an lvalue or an rvalue):
 
 The_Stack.Top := The_Stack.Top + 1;"


The problem with selectors such as this is when you have concurrency.
To provide atomicity of operations with selectors requires the client
of an abstraction to provide the appropriate guards.

If you have the update encapsulated (as in Update_Top), you can 
centralise the locking protocols in the abstraction.

Dale