[e-lang] Auditors

Stephan van Staden stephanvanstaden at tuks.co.za
Mon Jun 4 08:35:28 EDT 2007


Kevin Reid wrote:
> On Jun 1, 2007, at 5:50, Stephan van Staden wrote:
>
>   
>> Thanks for the insightful responses to my questions. Mr. Reid, I  
>> wish to
>> know what you mean when you say that auditing with eventual auditors
>> would be a source of mutability. Should I interpret this statement in
>> terms of the E-on-CL auditing framework where auditors have direct
>> access to the values of instance variables of objects being audited?
>>     
>
> No; it is independent of the audition protocol. Here's a hypothetical  
> session with eventual-allowed auditors:
>
> ? someRemoteAuditor
> # value: <Far ref>
>
> ? [def foo implements someRemoteAuditor {},
>  >  __approvedBy(someRemoteAuditor, foo)]
> # value: [<foo>, false]
>
> ...wait...
>
> ? __approvedBy(someRemoteAuditor, foo)
> # value: true
>
> Since the auditor is far, and an object's creation is immediate, the  
> first __approvedBy cannot know the result of the audit yet; the  
> second one, after the auditor has responded, does.
Yes, I agree.
> The response of  
> __approvedBy(someRemoteAuditor, foo) is therefore a mutable property  
> of foo.
>   
Is __approvedBy(someRemoteAuditor, foo) a property of foo or is it a 
property about foo? As I have it, approval by an auditor is an assertion 
about foo that depends on the properties (AST & syntactic environment) 
of foo. However, the audit will leave foo intact, since whether 
__approvedBy(someRemoteAuditor, foo) is true or false is already 
implicit in the properties of foo.
> Having __approvedBy return a promise in the first case would still be  
> a mutation (the promise resolving), which would require either foo or  
> __approvedBy to be not considered DeepFrozen;
Yes, I would regard __approvedBy not as DeepFrozen and part of the 
auditing system.
> it is also impossible  
> to know immediately the set of auditors for which promises rather  
> than false should be returned, since an auditor can ask/1 for other  
> auditors to be applied to the object being audited.
>   
I guess this problem would vanish If all auditors returned promises. 
However, always returning a promise might increase auditing overhead. 
The question is, of course, whether eventual auditing is or may become a 
useful feature.

Best,
Stephan


More information about the e-lang mailing list