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/>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.