Re: 'Protected' abstract subprograms

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 15 Jan 2014 09:11:03 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Yep, that's what I meant under "cooperative" privacy. For many
>> applications, and the number of is growing rapidly, a "non-cooperative"
>> privacy is needed as well.
> 
> Well, in a language that allows Unchecked_Conversion, address clauses,
> machine code inserts, etc., I don't see any way to achieve
> non-cooperative privacy within a single process.

Using memory protection and routing certain calls through the sealed RTL.
Just the way most OSes do it. Of course RTL could use certain OS services
for that, like it does in the case of tasks mapped on system threads. E.g.
a part of RTL could be implemented as a driver etc.

> You can achieve it
> in Ada via remote procedure calls, though.

Yes, though using network connection is much overhead comparing to
switching contexts. Furthermore RPC is a procedural paradigm unsuitable for
the purpose of privacy in an OO language like Ada, too much heavy-weight.

As a challenge for uncooperative privacy consider User_Credentials object.
Its implementation would store the password inaccessible otherwise than
through operations provided. The instances are kept on memory pages
unmapped for the rest of the program. The bodies of the operations run on
another context, which is switched upon the call. The call also validates
the object's 'reference' and converts it to the true address.

Though from the programmer's perspective semantically the difference from
protected objects Ada already has is not that big, if any.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de