[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