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

Kevin Reid kpreid at mac.com
Tue Aug 7 13:09:35 EDT 2007

On Aug 7, 2007, at 10:40, David Chizmadia (JHU) wrote:
> Kevin Reid wrote:
>> Selfish objects: those whose identity identity is defined by their
>> unique event of creation.
>> Selfless objects: those whose identity is determined by their
>> components, traversed via __optUncall.
>> The above definitions are well-established (I think), but not
>> complete. There is a class of objects whose identity is not unique to
>> their creation, and do not reveal their components:
> ...
>> Questions:
>>    * What should this third category be called? (I'll use "Atomic"
>> for purposes of the next question.)
>     As I read your description, I was struck by the fact that the
> identity of the objects you named seems to be defined by their state
> (usually a single value, but I think it generalizes).

In the cases of SturdyRef, TraversalKey, and Proxy, the state is  
multiple values.

The part which is relevant to clients is "Can I usefully attach a  
finalizer to this object?" and "If I __optUncall this object, will it  
return a non-null and correct answer?" (which is true for normal- 
Selfless and false for what-we-want-to-name).

> So I would
> suggest that this third class be called SelfEvident, with a parallel
> definition of:
> SelfEvident objects: those whose identity is (uniquely?) defined by
> their (DeepFrozen?) state.

This is pretty much the same definition as Selfless. The  
distinguishing characteristic is that they do not *reveal* their  
state (and also that they cannot be unsettled); so "evident" seems  
entirely the wrong direction to me.

If anything, perhaps "self-evident" might be used as a name for the  
not-Selfish-but-not-Transparent category.

The objects are not necessarily DeepFrozen: particularly, SturdyRefs  
carry authority to communicate to a remote vat, and Proxies might or  
might not have DeepFrozen message-handlers, but usually don't (they  
implement far refs and remote promises).

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

More information about the e-lang mailing list