[cap-talk] Last Call for ref_send API 1.0

[Kevin Reid]

On Apr 9, 2007, at 17:12, Tyler Close wrote:
> On 4/4/07, Kevin Reid <kpreid at mac.com> wrote:
>> Question: What does Eventual#ready do? The documentation and example
>> don't make it clear what the difference between its input and its
>> output are.
>
> In the ref_send library, unlike in the E language, a promise for an
> object is distinct from an eventual reference for an object. This
> design is an artifact of Java's static type system. I can't make a
> promise for an Integer polymorphic with an Integer. The same is true
> for any non-interface. The cast() method converts a promise to an
> eventual reference. The ready() operation does the inverse conversion.
>
> To avoid explaining the above, I've hidden the ready() method behind
> an overload of the when() method. Is this less confusing for you?

Yes. I also think the original situation would be acceptable given a  
better explanation of ready() in the documentation (such as the one  
you give here).

>> Question: The documentation does not state explicitly that a resolved
>> Promise will (allegedly) from then on return the same value from
>> every call to cast(). Is this the case?
>
> A promise created by the defer() method can only be resolved once and
> stays in that resolved state forever.

I think you're agreeing with me, but this phrasing doesn't really  
make it clear. I infer that by "that resolved state" you mean a state  
of being resolved /to a particular reference/ (that is, that being  
resolved to some other reference would be "a different resolved  
state"), but I wouldn't think that except for the context of my  
question above. I request that this be stated more clearly.

>> Comment: E-on-Java provides Ref.makeSwitchablePromise, which has a
>> somewhat similar effect to ref_send's Volatile (if I understand it
>> correctly). <http://www.erights.org/javadoc/org/erights/e/elib/ref/
>> Ref.html#makeSwitchablePromise(java.lang.Object)> This behavior can
>> also be built out of the proxy protocols (EProxyResolver/makeProxy).
>
> Interesting. The Volatile interface primarily exists to call out that
> clients must be prepared to handle this behavior, since Promise
> behavior cannot be guaranteed. I had made the Variable interface
> compatible with Volatile to make this behavior available as intended
> and agreed behavior, instead of just aberrant behavior. MarkM and
> others were uncomfortable with these semantics. It's interesting that
> something similar exists in ELib.

*If* I understand correctly from talking with MarkM and Dean, the  
uncomfortability was not from that a volatile reference could switch,  
but that a *promise* could switch. I also would object to such  
semantics, but I believe that you do not intend them, so if I  
understand correctly, there is no objection.

(Note that in E, a switchable promise is necessarily an *unresolved*  
eventual reference, just like a regular promise, whereas an ordinary  
(Far) eventual reference to some object is resolved, so the  
switchability is detectable by the programmer; in particular, a when/ 
whenResolved will not trigger until the reference becomes resolved.)

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