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

[Kevin Reid]

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:

   * SturdyRef
   * TraversalKey
   * boxed numbers
   * String
   * Proxy

One possible answer is to call these Selfish; this is what E-on-CL  
does from the E programmer's perspective. This is mostly externally  
consistent. However, our discussion last Wednesday assumed (!) that  
any Selfish object has the property that once finalizers are invoked  
on it, that identity cannot reoccur.

E-on-CL's implementation calls these objects "atomic", but does not  
expose this category to the programmer. The name was chosen to refer  
to objects like strings and numbers; it doesn't, though, seem too  
unreasonable to apply it to *observably* indivisible objects like  
SturdyRefs.

http://www.erights.org/elib/equality/same-object.html calls a subset  
of these objects "Scalars", and does not address the identity of  
SturdyRefs etc.

E-on-Java calls these objects "honorary Selfless", which is a name  
derived from the idea that these objects existed before E, which is  
not true in all cases.

If we want "def foo implements Selfless {...}" to mean that the  
object's __optUncall is used to compare it, then these objects should  
not be considered Selfless since they do not have __optUncall.

Such objects (particularly, SturdyRefs in E-on-CL) should be  
implementable from E. The obvious way to do this is to do it like  
Selfless, except using sealed dispatch to provide the uncall (with  
Equalizer holding the unsealer). The same uncall could be used (with  
a different sealer) for persistence of those objects.

Questions:

   * What should this third category be called? (I'll use "Atomic"  
for purposes of the next question.)

   * Should it be considered a subcategory of Selfless, and if so,  
what are Selfless but not Atomic objects called? ("Transparent" would  
imply one has to write "def foo implements TransparentSelfless {}"  
which seems a bit ugly to me.)

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