Types, Makers, and Inheritance

[Tyler Close]

At 02:21 PM 10/20/98 -0700, you wrote:
>But hey... why me?  :)  I like making diagrams.  (Remember the state
>transition diagram for Promises?)  I guess i'm really asking both of you.

Ya, that's a good point. Let's simplify that diagram too. :-)

I suspect that the complexity of this diagram is the source of our
difficulty in defining the equals() method.

Normally when you have a bunch of if / else blocks, like we do in the
proposed implementation of the equals() method, it's a dead giveaway that
you are mixing types. Doesn't it seem downright strange to you that every
time that you compare two references, you have to re-check that they have
both been resolved? I suspect that Promises should be implemented as first
class objects rather than primitive references. This would clarify the fact
that once a Promise is resolved, it stays resolved. You could then lock in
this information by extracting the primitive reference from the Promise.

I see this as analogous to the SoftReference class in Java. In Java, a
SoftReference is an object that holds a reference that the garbage
collector can clear at will to reclaim memory. I see Promise objects as the
symmetrical case, an object which holds a reference that the vat will set
when the Promise is fulfilled.

I believe taking this approach will dramatically simplify the equals method
and avoid the need for the multiple return values that were being discussed.

Tyler