[e-lang] multiway when-catch
Rob Withers
reefedjib at yahoo.com
Thu Nov 1 22:16:03 EDT 2007
----- Original Message -----
From: "Kevin Reid" <kpreid at mac.com>
To: "Discussion of E and other capability languages"
<e-lang at mail.eros-os.org>
Sent: Thursday, November 01, 2007 2:49 PM
Subject: Re: [e-lang] multiway when-catch
> On Oct 29, 2007, at 22:36, Rob Withers wrote:
>
>>> Okay, this looks reasonable, though it's more mutable than is good
>>> style. However, whenResolved is not a primitive operation on
>>> references. Look at jsrc/org/erights/e/elib/ref/Ref.java for the
>>> implementation of whenResolved.
>>
>> I see that, now that you point it out. I am sure there is a good
>> reason for
>> it. Is it because you want to limit the MirandaMethods defined, and
>> __whenMoreResolved handles the behavior of what you want, so
>> whenResolved
>> and whenBroken are specified in terms of __whenMoreResolved? Or
>> are there
>> other reasons?
>
> Design principle: Operations should be as simple and un-duplicative
> as possible; having overlapping operations allows misbehaving
> implementations to implement them differently.
>
> Also, since there are many things which must be aware of the entire
> Miranda protocol (forwarders, membranes, other-object-system
> bindings, etc.) it is good to minimize the complexity each must
> reimplement/understand.
I need to take a steady look at the Miranda protocol and adopt it or an
equivalent functionality. I have made it Phase 3 of my Plan.
>
> Also, Ref.whenResolved has stronger guarantees than
> __whenMoreResolved which derive exactly from that it is a separate
> implementation. For examples, for any Ref.whenResolved(x, f),
>
> 1. f will not be invoked until x *really is* completely resolved
> (as defined by Ref.isResolved), rather than when it is more-resolved
> or pretending to be resolved.
While using my implementation of CapTP may provide more-resolved situations
to occur, locally I presently don't have buffering or switching refs, and I
do implicit shortening with #becomeForward:. But I should ensure that
#whenMoreResolved is called with code that ensures #isResolved before
invoking f, called from #whenResolved:. #whenResolved: and #isResolved are
currently implemented on the instance side of my Refs.
> 2. f will be invoked at most once.
Yes.
> 3. f will be passed a reference which is the same as x.
Yes.
Thank you very much for this clear explaination. If only I could think this
clearly about these problems,
Rob
More information about the e-lang
mailing list