[e-lang] What's a SturdyRef (or TraversalKey, String, ...), anyway?

[Kevin Reid]

On Aug 7, 2007, at 12:02, David Hopwood wrote:
> I thought that such objects should be considered Selfless but not
> Transparent?
>
> (see Figure 3 of <http://www.erights.org/elang/kernel/auditors/>)
> ...
> "Do not reveal [all of] their components" is absence of an  
> auditable property. So I am not sure that this category needs a  
> specific name. Why is "Selfless && !Transparent" not sufficient?

I'm starting to think that this may be the right answer; especially  
as I've thought of two categories of S&!T objects:

   - those compared in some primitive way (e.g. integers).
   - those compared, like S&T, by an uncall (portrayal), but not one  
revealed to all clients.

I accept that we shouldn't have a specific name for S&!T, and that  
the objects I was asking about are S&!T.

Given this, the stamp (not yet true auditor) I'm calling  
SelflessStamp in E-on-CL must be renamed, as it really means  
SelflessTransparentStamp.

I imagine splitting it into TransparentStamp and Selfless. Selfless  
auditing would consist of verifying that the object provides some  
reliable comparison; TransparentStamp being one of them.

(Auditing for transparency is nontrivial, as it not only involves the  
object's definition, but also its maker, which must be shown to  
produce a similar object when given the object's uncall message.)

> Note that !Transparent does not imply "always keeps all of its  
> components
> secret".

Is a FlexList Transparent? It reveals all of its components, though  
it is Selfish, and can be accurately copied by its uncall (if and  
only if its element guard is idempotent).

>>    * Should it be considered a subcategory of Selfless, and if so,  
>> what are Selfless but not Atomic objects called?
>
> PassByCopy (again, see Figure 3).

No, this is necessary but not sufficient: A Selfless and Transparent  
object whose maker is not PassByConstruction is not PassByCopy,  
because it would necessarily fail to unserialize.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>