Re: multiway when-catch
Kevin Reid <[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
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. 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. 2. f will be invoked at most once. 3. f will be passed a reference which is the same as x. There are probably other reasons I haven't thought of (MarkM?). -- Kevin Reid <http://homepage.mac.com/kpreid/>