[cap-talk] Last Call for ref_send API 1.0

[Tyler Close]

On 4/2/07, Dean Tribble <tribble at e-dean.com> wrote:
> I'm delighted that Facet does not apear in the API :-).

The Struct name also came from you via MarkM, since you talked about
using C# structs to do something similar.

> The two other names
> I'd recommend changing:
>
> Closure is a very common concept that is only loosely reflected it the
> decalred interface.

Errr.. "only loosely". Please explain.

>  I have a vague recollection that Java has an existing
> variant of Runnable that might do.

Nothing that I'm aware of.

> As for "Channel"...!  Just returning a struct of a Promise and a Resolver is
> a pretty measly purpose for polluting the term "Channel"!

Actually, I think this "Channel" corresponds well to a Joule channel.
The defer() method happens to create a channel that can be resolved
only once. I believe MarkM is working on an implementation that
returns a channel that can be resolved more than once, like Joule's
channel.

As for polluting the term. Joule channels don't even rate a mention on
the Wikipedia page about channels:

http://en.wikipedia.org/wiki/Actor_model_and_process_calculi#How_do_channels_work.3F

The org.ref_send.promise.eventual.Channel corresponds well to the
asynchronous channel documented on that Wikipedia page.

>  I think the
> primary reason for that is the lack of multiple return values.  If so, then
> just defining Pair<T,U> would allow that pattern to appear in multiple
> places without needing to define a new term for every occurrence.

This would hurt code readability. Take a look at the async AND
implementation at:

http://waterken.sourceforge.net/javadoc/src-html/org/ref_send/test/Logic.html#line.50

Changing lines like:

    answer.resolver.resolve(false);

to something like:

    answer.second.resolve(false);

is not an improvement.

Despite MarcS' seconding of this idea, I still don't like it. Can you
improve upon it?

Tyler