Re: [cap-talk] __equalizer and such E operations

I may quickly get deeper into the language structures
that is meaningful for me to follow, but just briefly on:

On 2/12/2008 4:27 PM, Kevin Reid wrote:
> On Feb 12, 2008, at 18:54, Jed Donnelley wrote:
...
>>   It provides information that could not otherwise be obtained  
>> about objects.  Can you give us an idea of how many such objects or  
>> other primitives there are
>> that relate to the base domain protection in E?
> 
> I'm not sure what primitives you would consider to 'relate to the  
> base domain protection',

I guessed that phrase might be problematic.  It seems that
trying to say it in two ways (info/operations that couldn't
be otherwise programmed - necessarily primitive) didn't help?

Regarding:

>    __auditedBy (tests whether an object has been approved by a  
> particular auditor; this may be analogous to the "MyCap?" being  
> discussed)

No, "MyCap?" is quite different.  I think the closest analog in
the OO language area is being in the scope of an object method
and therefore being able to operate on the private parts of
an object.  As Charlie noted, in the language arena this
scoping is implicit.  In an OS or network context, there is
no such scoping to rely on.  There has to be some means for
an executing program to demonstrate it's permission to
get access to the 'insides' of an object that it was
passed as a parameter.  That's "MyCap?" or equivalents
as Charlie noted in KeyKOS, CapROS, etc.

>> in particular when you said 'the latter may invoke the code of the  
>> object'.  What sort of object property could induce __equalizer to  
>> invoke "the" object?
> 
> Selfless; the auditor-granted property that its creation-identity is  
> invisible and it is compared by structure instead. Both objects in  
> the comparison are invoked (__optUncall/0) to request their self- 
> descriptions for traversal.
> 
> Selfless objects are all immutable (but not transitively).

Are these "selfless" objects in some sense "built in"?

>> By "the" object, I assume you mean the first of the two objects -  
>> or is it more complex than that?
> 
> If both objects are Selfless, both are invoked, and the resulting  
> lists compared recursively; otherwise, neither is.

I wonder if an example might help?  On the surface, making objects
selfless appears to make more work to compare them when a pointer
compare would otherwise suffice.  What's the offsetting gain?

Thanks for taking time to explain Kevin!

--Jed  http://www.webstart.com/jed/