Tyler Close | 1 Apr 06:33 2007
Picon

Last Call for ref_send API 1.0

Hi all,

In an effort to get a 1.0 release for ref_send, I've been pruning the
API and documenting what's left. As it stands, the library provides
only what's needed to do eventual control flow within a single,
transient, Java thread. I suspect this narrowly focused API could be
useful to a wide array of applications, and hope freezing the API will
encourage such use.

I've just uploaded the "Last Call" version of the ref_send API, v0.18,
to SourceForge. You can get it at:

http://waterken.sourceforge.net/download.html

The Javadoc for the API is online at:

http://waterken.sourceforge.net/javadoc/

Stamping the ref_send API as 1.0 will mean that backwards
compatibility will be maintained. So this is your last chance to gripe
about the names and patterns used in the API. After that, we're stuck
with it.

Thanks for your feedback.

Tyler

--

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/
(Continue reading)

James A. Donald | 2 Apr 06:26 2007

Re: Interesting article on virtual currency

James Graves wrote:
 > There's an interesting article in today's Wall Street
 > Journal about the virtual currency, called QQ,
 > initially created by Tencent Holding Ltd.
 >
 > It started out as a play currency for in-game bonuses.
 > But since then it has started being used for
 > real-world transactions too.  China's government isn't
 > happy about that.
 >
 > There are also many issues surrounding a currency
 > being used far outside its intended use.  Stuff like
 > conversions between yuans and QQ are often done in a
 > woefully insecure manner.  All of which could have
 > been avoided from the start by studying the literature
 > on the subject, but no one was thinking that far
 > ahead.
 >
 > Another case of worse is better, I suppose.

The moral of the QQ story is that internet messaging
should not only support text, audio, and video, it
should also support a means of exchanging and
transferring promises, for when one person talks to
another, the topic is often what one of them can do for
the other.
James A. Donald | 2 Apr 07:58 2007

Re: Animation software (was Re: New horton animation up)

Pierre THIERRY wrote:
> Wanting to understand various capability-related topics, and after that,
> wanting to explain them to others made me wish harder for a some kind of
> powerful animation software for such diagrams.

Flash.
David Wagner | 2 Apr 23:12 2007
Picon

Last Call for ref_send API 1.0

Tyler Close writes:
>...last chance to gripe about the names and patterns used in the API...

Works for me.  I have no gripes about anything in org.ref_send*.

I wrote down some minor comments below.  I believe they can all be
added later, either because they are backwards-compatible changes or
because they are Javadoc changes or because they only affect the
org.joe_e* libraries, so they may not be important now, but I wanted
to write them down while they were fresh in my mind.

org.ref_send:

Record: The Javadoc calls this "A pass-by-construction object.", but
I think you mean "An allegedly pass-by-construction object." -- is that
correct?  (Nothing enforces that this Record instances are indeed
pass-by-construction; it's up to the programmer to manually respect
the semantics of pass-by-construction objects.  Recipients of a Record
object should not rely upon it to be pass-by-construction.)

 <at> cacheable: Do you mean "an allegedly cacheable property"?

org.ref_send.promise:

Given the comments in Var's Javadoc, would it be useful to provide
a class that acts as a sensory facet to a Var (or other mutable Volatile)
that only provides authority to read the Volatile?  Something like:

    public final class VolatileFacet<T> implements Volatile<T> {
        private final Volatile ref;
(Continue reading)

Dean Tribble | 3 Apr 07:14 2007

Re: Last Call for ref_send API 1.0

I'm delighted that Facet does not apear in the API :-).  The two other names I'd recommend changing:
 
Closure is a very common concept that is only loosely reflected it the decalred interface.  I have a vague recollection that Java has an existing variant of Runnable that might do.  If not, perhaps just a naming convention that permits of functions with more an less than one argument would be sufficient ( e.g., Closure1 or Fn1).
 
As for "Channel"...!  Just returning a struct of a Promise and a Resolver is a pretty measly purpose for polluting the term "Channel"!  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. 
 
Cheers!
Dean
 
On 4/2/07, David Wagner <daw-Sd3DkRwxp1uueSrTVlFI5A@public.gmane.org> wrote:
Tyler Close writes:
>...last chance to gripe about the names and patterns used in the API...

Works for me.  I have no gripes about anything in org.ref_send*.

I wrote down some minor comments below.  I believe they can all be
added later, either because they are backwards-compatible changes or
because they are Javadoc changes or because they only affect the
org.joe_e* libraries, so they may not be important now, but I wanted
to write them down while they were fresh in my mind.


org.ref_send:

Record: The Javadoc calls this "A pass-by-construction object.", but
I think you mean "An allegedly pass-by-construction object." -- is that
correct?  (Nothing enforces that this Record instances are indeed
pass-by-construction; it's up to the programmer to manually respect
the semantics of pass-by-construction objects.  Recipients of a Record
object should not rely upon it to be pass-by-construction.)

<at> cacheable: Do you mean "an allegedly cacheable property"?


org.ref_send.promise:

Given the comments in Var's Javadoc, would it be useful to provide
a class that acts as a sensory facet to a Var (or other mutable Volatile)
that only provides authority to read the Volatile?  Something like:

   public final class VolatileFacet<T> implements Volatile<T> {
       private final Volatile ref;
       public VolatileFacet(T value) { ref = value; }
       public T cast() { return ref.cast (); }
   }

Then the suspect code mentioned in Var's Javadoc could be conveniently
re-written as follows, if the intent was to provide only read-only access
to the balance:

   public Volatile<Integer> getBalance() {
       return new VolatileFacet(balance);
   }

I don't know if "VolatileFacet" is the best name.  Of course, adding
such a class is a backwards-compatible change, so doesn't need to be
done now.

Resolved: The Javadoc for ref() doesn't say whether the caller can rely
upon the return value to be a trustworthy Resolved promise that resolves
to "value" (the argument to ref()).

I have no idea what detach() is doing, so it is hard for me to know
whether this is the best name.  At a minimum, it needs to be documented
better.  (For instance, how does it differ from ref()?)  Do I get to
reserve the right to gripe about detach()'s name once I understand what
it is doing? :-)

Eventual: The Javadoc at the top is very, very nice.

I don't understand what ready() is doing, or what is meant by
"the underlying reference implementation".  What is a "reference
implementation"?  Does it mean some sample implementation that the
ref-send library provides?  Also, what can the caller assume about the
Volatile returned by ready()?  Is it guaranteed to be trustworthy, to
only resolve once, etc.?  I do not understand the example for ready():
what does it mean to register an observer on an immediate value with type
"Account"?  When does the observer get invoked?  Under what conditions
would the result of applying ready() to an immediate reference cause
the resulting Volatile to be rejected?

I didn't understand the Javadoc for cast(), what cast() is doing,
what the purpose of the "expected" argument is for, or what proxy
the Javadoc is referring to.  Would more explanation help?  Would an
example help?

The documentation should probably specify what is meant by an
"allowed proxy type", or link/refer to the appropriate specification
in the Java class library documentation.



org.ref_send.promise.eventual.Loop: Ok, I admit I may not know how
to parse Java generics correctly.  Does the name "Task", in the defn
of the Loop interface, refer to a generic type parameter, or does it
refer to org.ref_send.promise.Task?  I'm guessing it is the former.
If so, that is incredibly confusing.  Standard Java convention is to use
one-letter capital letters for generic type parameters.  It's even worse
to make the name of a generic type parameter be the same as the name of
a public class/interface defined elsewhere in your API.  I suggest that
you change the defn of Loop to either

   public interface
   Loop<T extends Closure<Void,?>> extends Closure<T,Void> {
       Void post(T closure);
   }

or to

   import org.ref_send.promise.Task;

   public interface
   Loop extends Closure<Task,Void> {
       Void post(Task task);
   }

according to your intent.  I'm guessing you intended the former, so the
change should be backwards-compatible, but please check for yourself.


org.joe_e.Keeper: The name "Keeper" doesn't mean anything to me.
It sounds like a generic concept, but org.joe_e.Keeper is used for a
very narrow purpose.  It would be a shame to take up a name that might
profitably be better used for something else, and it might be nice if
the name here was more evocative.  How about "ErrorHandler"?


org.joe_e.crypto.AES: Out of curiousity, why does this need to be in
the org.joe_e namespace?  Is AES something that pure Joe-E code cannot
implement?  Or is this an optimized implementation that uses native
methods or something?


org.joe_e.file.Filesystem:

list() shouldn't throw NullPointerException when the argument isn't a
directory.  Use some other exception.  Only throw NullPointerException
when the argument is null.  I guess this is not a backwards-compatible
change, so it needs to be done now.

name() should document that the "child" argument must be a single
filename component, not a relative path.  For instance, "../foo" or
"foo/bar" are right out.

vet() should document whether it is intended to be applied to a single
filename component, a relative path, and/or an absolute path.  Also,
I couldn't extract what the second sentence in the Javadoc for vet()
is trying to convey, though I suspect it is related.


org.joe_e.reflection.Reflection: I have reservations about the semantics
of some of the methods.  I feel like it would be beneficial to have
more discussion before it is ready to be inserted into a Joe-E library
which Joe-E promises to support forever.  Your choices may be fine for
users of ref-send, but for what goes into Joe-E libraries, I think the
question has to be about what is right for all Joe-E users.


org.ref_send.list.List: I'm curious about why you named the method
"getSize()" rather than "size()", as the latter seems to be the standard
name used by the Java collections classes.  Have you considered making
this implement java.util.List?  I suspect you have and decided it was
overkill.  Also, remind me some day to ask you why you added this class
rather than, say, java.util.LinkedList.


org.ref_send.promise.{curry ,test}.*: I didn't look at any of this.
(I got tired.)
_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Marc Stiegler | 3 Apr 19:57 2007

Re: Last Call for ref_send API 1.0

I want to register agreement with Dean about the use of the term Channel, though for a different reason. "Pair" immediately conveys at least a small clue about what it going on. "Channel" only speaks to those who already know what this stuff is -- the least important audience.

--marcs

On 4/2/07, Dean Tribble <tribble-9OagEyESeoDQT0dZR+AlfA@public.gmane.org> wrote:
I'm delighted that Facet does not apear in the API :-).  The two other names I'd recommend changing:
 
Closure is a very common concept that is only loosely reflected it the decalred interface.  I have a vague recollection that Java has an existing variant of Runnable that might do.  If not, perhaps just a naming convention that permits of functions with more an less than one argument would be sufficient ( e.g., Closure1 or Fn1).
 
As for "Channel"...!  Just returning a struct of a Promise and a Resolver is a pretty measly purpose for polluting the term "Channel"!  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. 
 
Cheers!
Dean
 
On 4/2/07, David Wagner <daw-Sd3DkRwxp1uueSrTVlFI5A@public.gmane.org > wrote:
Tyler Close writes:
>...last chance to gripe about the names and patterns used in the API...

Works for me.  I have no gripes about anything in org.ref_send*.

I wrote down some minor comments below.  I believe they can all be
added later, either because they are backwards-compatible changes or
because they are Javadoc changes or because they only affect the
org.joe_e* libraries, so they may not be important now, but I wanted
to write them down while they were fresh in my mind.


org.ref_send:

Record: The Javadoc calls this "A pass-by-construction object.", but
I think you mean "An allegedly pass-by-construction object." -- is that
correct?  (Nothing enforces that this Record instances are indeed
pass-by-construction; it's up to the programmer to manually respect
the semantics of pass-by-construction objects.  Recipients of a Record
object should not rely upon it to be pass-by-construction.)

<at> cacheable: Do you mean "an allegedly cacheable property"?


org.ref_send.promise:

Given the comments in Var's Javadoc, would it be useful to provide
a class that acts as a sensory facet to a Var (or other mutable Volatile)
that only provides authority to read the Volatile?  Something like:

   public final class VolatileFacet<T> implements Volatile<T> {
       private final Volatile ref;
       public VolatileFacet(T value) { ref = value; }
       public T cast() { return ref.cast (); }
   }

Then the suspect code mentioned in Var's Javadoc could be conveniently
re-written as follows, if the intent was to provide only read-only access
to the balance:

   public Volatile<Integer> getBalance() {
       return new VolatileFacet(balance);
   }

I don't know if "VolatileFacet" is the best name.  Of course, adding
such a class is a backwards-compatible change, so doesn't need to be
done now.

Resolved: The Javadoc for ref() doesn't say whether the caller can rely
upon the return value to be a trustworthy Resolved promise that resolves
to "value" (the argument to ref()).

I have no idea what detach() is doing, so it is hard for me to know
whether this is the best name.  At a minimum, it needs to be documented
better.  (For instance, how does it differ from ref()?)  Do I get to
reserve the right to gripe about detach()'s name once I understand what
it is doing? :-)

Eventual: The Javadoc at the top is very, very nice.

I don't understand what ready() is doing, or what is meant by
"the underlying reference implementation".  What is a "reference
implementation"?  Does it mean some sample implementation that the
ref-send library provides?  Also, what can the caller assume about the
Volatile returned by ready()?  Is it guaranteed to be trustworthy, to
only resolve once, etc.?  I do not understand the example for ready():
what does it mean to register an observer on an immediate value with type
"Account"?  When does the observer get invoked?  Under what conditions
would the result of applying ready() to an immediate reference cause
the resulting Volatile to be rejected?

I didn't understand the Javadoc for cast(), what cast() is doing,
what the purpose of the "expected" argument is for, or what proxy
the Javadoc is referring to.  Would more explanation help?  Would an
example help?

The documentation should probably specify what is meant by an
"allowed proxy type", or link/refer to the appropriate specification
in the Java class library documentation.



org.ref_send.promise.eventual.Loop: Ok, I admit I may not know how
to parse Java generics correctly.  Does the name "Task", in the defn
of the Loop interface, refer to a generic type parameter, or does it
refer to org.ref_send.promise.Task?  I'm guessing it is the former.
If so, that is incredibly confusing.  Standard Java convention is to use
one-letter capital letters for generic type parameters.  It's even worse
to make the name of a generic type parameter be the same as the name of
a public class/interface defined elsewhere in your API.  I suggest that
you change the defn of Loop to either

   public interface
   Loop<T extends Closure<Void,?>> extends Closure<T,Void> {
       Void post(T closure);
   }

or to

   import org.ref_send.promise.Task;

   public interface
   Loop extends Closure<Task,Void> {
       Void post(Task task);
   }

according to your intent.  I'm guessing you intended the former, so the
change should be backwards-compatible, but please check for yourself.


org.joe_e.Keeper: The name "Keeper" doesn't mean anything to me.
It sounds like a generic concept, but org.joe_e.Keeper is used for a
very narrow purpose.  It would be a shame to take up a name that might
profitably be better used for something else, and it might be nice if
the name here was more evocative.  How about "ErrorHandler"?


org.joe_e.crypto.AES: Out of curiousity, why does this need to be in
the org.joe_e namespace?  Is AES something that pure Joe-E code cannot
implement?  Or is this an optimized implementation that uses native
methods or something?


org.joe_e.file.Filesystem:

list() shouldn't throw NullPointerException when the argument isn't a
directory.  Use some other exception.  Only throw NullPointerException
when the argument is null.  I guess this is not a backwards-compatible
change, so it needs to be done now.

name() should document that the "child" argument must be a single
filename component, not a relative path.  For instance, "../foo" or
"foo/bar" are right out.

vet() should document whether it is intended to be applied to a single
filename component, a relative path, and/or an absolute path.  Also,
I couldn't extract what the second sentence in the Javadoc for vet()
is trying to convey, though I suspect it is related.


org.joe_e.reflection.Reflection: I have reservations about the semantics
of some of the methods.  I feel like it would be beneficial to have
more discussion before it is ready to be inserted into a Joe-E library
which Joe-E promises to support forever.  Your choices may be fine for
users of ref-send, but for what goes into Joe-E libraries, I think the
question has to be about what is right for all Joe-E users.


org.ref_send.list.List: I'm curious about why you named the method
"getSize()" rather than "size()", as the latter seems to be the standard
name used by the Java collections classes.  Have you considered making
this implement java.util.List?  I suspect you have and decided it was
overkill.  Also, remind me some day to ask you why you added this class
rather than, say, java.util.LinkedList.


org.ref_send.promise.{curry ,test}.*: I didn't look at any of this.
(I got tired.)
_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk


_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk


_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Tyler Close | 4 Apr 05:49 2007
Picon

Re: Last Call for ref_send API 1.0

Hi David,

Thank you for the continued effort. I really appreciate it.

Responses inline below.

On 4/2/07, David Wagner <daw@...> wrote:
> ... or because they only affect the
> org.joe_e* libraries, so they may not be important now, but I wanted
> to write them down while they were fresh in my mind.

We should identify the org.joe_e.* interfaces that Adrian is unwilling
to let people depend on and I'll remove them from the ref_send 1.0
distribution. I'ld like to put together a distribution that people can
start coding to without worrying that the rug will be pulled out from
under them.

I think the barest minimum ref_send requires is org.joe.*,
org.joe_e.reflection.Reflection.{allowed, invoke, peel, proxy}

The next piece of the Waterken Server I'll have ready for distribution
is the HTTP client/server implementation. This code further depends on
org.joe_e.file.* and org.joe_e.charset.*.

After that, the remoting library depends on the rest of the Joe-E API.

I put these APIs under org.joe_e since they can't be implemented by
Joe-E code, but are dependencies of Joe-E code. I suppose I could also
create my own trusted Java library to hold these APIs, rather than
bundle them all in org.joe_e. Is that preferable?

> org.ref_send:
>
> Record: The Javadoc calls this "A pass-by-construction object.", but
> I think you mean "An allegedly pass-by-construction object." -- is that
> correct?  (Nothing enforces that this Record instances are indeed
> pass-by-construction; it's up to the programmer to manually respect
> the semantics of pass-by-construction objects.  Recipients of a Record
> object should not rely upon it to be pass-by-construction.)
>
>  <at> cacheable: Do you mean "an allegedly cacheable property"?

The above statements are correct, but they're also correct for all
interfaces that are not the special org.joe_e.* verified interfaces.
Do we want to adopt the "allegedly" convention when documenting all
Joe-E interfaces?

> org.ref_send.promise:
>
> Given the comments in Var's Javadoc, would it be useful to provide
> a class that acts as a sensory facet to a Var (or other mutable Volatile)
> that only provides authority to read the Volatile?  Something like:
>
>     public final class VolatileFacet<T> implements Volatile<T> {
>         private final Volatile ref;
>         public VolatileFacet(T value) { ref = value; }
>         public T cast() { return ref.cast(); }
>     }
>
> Then the suspect code mentioned in Var's Javadoc could be conveniently
> re-written as follows, if the intent was to provide only read-only access
> to the balance:
>
>     public Volatile<Integer> getBalance() {
>         return new VolatileFacet(balance);
>     }
>
> I don't know if "VolatileFacet" is the best name.  Of course, adding
> such a class is a backwards-compatible change, so doesn't need to be
> done now.

I thought about doing something like the above but decided to put it
off until later since I don't have any code that needs such a facet
and, as you say, it's something that can be added without breaking
compatibility. Procrastination has served me well in the past, so I'm
going to stick to that plan.

> Resolved: The Javadoc for ref() doesn't say whether the caller can rely
> upon the return value to be a trustworthy Resolved promise that resolves
> to "value" (the argument to ref()).

Good catch. I'll update the Javadoc to indicate the returned promise
can be relied upon.

> I have no idea what detach() is doing, so it is hard for me to know
> whether this is the best name.  At a minimum, it needs to be documented
> better.  (For instance, how does it differ from ref()?)  Do I get to
> reserve the right to gripe about detach()'s name once I understand what
> it is doing? :-)

The detach() method is closely related to the List implementation you
ask about further down. The detach() method provides a hook that the
orthogonal persistence implementation picks up on. detach() returns a
promise that defers deserialization of the target object until the
cast() method of the promise is called. Applications use this method
to break up a large object graph so that only the parts needed for the
current operation get deserialized. For example, the List
implementation stores each element in the list in a detach()'ed
promise. As a result, you can pop() the first element of a list
without loading the whole list into memory.

> Eventual: The Javadoc at the top is very, very nice.

Thanks, though MarkM deserves a good deal of the credit here. This
text is basically just a rework of a passage from his dissertation.

> I don't understand what ready() is doing, or what is meant by
> "the underlying reference implementation".  What is a "reference
> implementation"?  Does it mean some sample implementation that the
> ref-send library provides?

Yes. An eventual reference is just a Java proxy wrapped around one of
the reference implementations documented in org.ref_send.promise. To
register a when block on the reference, you need to peel off the Java
proxy to get at the underlying reference implementation. The ready()
method implements this peeling. The return is guaranteed to be
anything. I named this method "ready" so that the line:

    x = foo_.bar();
    _.when(ready(x), new Do...

would read as "when x is ready, do ...", meaning when the bar()
invocation has been completed, do the following on its return value.
I'll try to come up with better Javadoc for this method.

> I didn't understand the Javadoc for cast(), what cast() is doing,
> what the purpose of the "expected" argument is for, or what proxy
> the Javadoc is referring to.  Would more explanation help?  Would an
> example help?

Hmmm... I'll take another crack at the Javadoc for this. cast()
creates an eventual reference given the type to implement and the
reference implementation.

> The documentation should probably specify what is meant by an
> "allowed proxy type", or link/refer to the appropriate specification
> in the Java class library documentation.

It does link to the specification. It links to
org.joe_e.reflection.Reflection.allowed.

> org.ref_send.promise.eventual.Loop: Ok, I admit I may not know how
> to parse Java generics correctly.  Does the name "Task", in the defn
> of the Loop interface, refer to a generic type parameter, or does it
> refer to org.ref_send.promise.Task?  I'm guessing it is the former.
> If so, that is incredibly confusing.  Standard Java convention is to use
> one-letter capital letters for generic type parameters.  It's even worse
> to make the name of a generic type parameter be the same as the name of
> a public class/interface defined elsewhere in your API.  I suggest that
> you change the defn of Loop to either
>
>     public interface
>     Loop<T extends Closure<Void,?>> extends Closure<T,Void> {
>         Void post(T closure);
>     }
>
> or to
>
>     import org.ref_send.promise.Task;
>
>     public interface
>     Loop extends Closure<Task,Void> {
>         Void post(Task task);
>     }
>
> according to your intent.  I'm guessing you intended the former, so the
> change should be backwards-compatible, but please check for yourself.

You correctly guessed my intent. I left this potential confusion in
there because either way of reading it is perfectly fine. If you think
you can only pass in a org.ref_send.promise.Task, that's fine. I was
thinking that the first definition you propose above could leave
someone who doesn't understand generics at a loss for what kind of
argument they are supposed to provide. The extends syntax is sort of
an advanced feature of Java generics. The current definition at least
suggests something that will work. It's only confusing to someone who
knows a fair bit about Java generics, and they can likely cope, as you
did.

> org.joe_e.Keeper: The name "Keeper" doesn't mean anything to me.
> It sounds like a generic concept, but org.joe_e.Keeper is used for a
> very narrow purpose.  It would be a shame to take up a name that might
> profitably be better used for something else, and it might be nice if
> the name here was more evocative.  How about "ErrorHandler"?

The name "Keeper" comes from either Dean or Norm I think. One of them
created this pattern of having a central piece of code that gets first
shot at handling errors. The name we use here is not so important
since it's not something application writers will interact with. The
interface only gets used by infrastructure code like the Waterken
Server. I'll defer to Adrian for naming this interface.

> org.joe_e.crypto.AES: Out of curiousity, why does this need to be in
> the org.joe_e namespace?  Is AES something that pure Joe-E code cannot
> implement?  Or is this an optimized implementation that uses native
> methods or something?

If you've got a pure Joe-E implementation of AES, I'll gladly use it
and deprecate this API. Otherwise, I need this API to safely wrap the
javax.crypto implementation.

> org.joe_e.file.Filesystem:
>
> list() shouldn't throw NullPointerException when the argument isn't a
> directory.  Use some other exception.  Only throw NullPointerException
> when the argument is null.  I guess this is not a backwards-compatible
> change, so it needs to be done now.

OK.

> name() should document that the "child" argument must be a single
> filename component, not a relative path.  For instance, "../foo" or
> "foo/bar" are right out.

OK.

> vet() should document whether it is intended to be applied to a single
> filename component, a relative path, and/or an absolute path.  Also,
> I couldn't extract what the second sentence in the Javadoc for vet()
> is trying to convey, though I suspect it is related.

Yup, that second sentence was trying to convey exactly what you want
it to convey. I'll change it to use the phrasing you use above.

> org.joe_e.reflection.Reflection: I have reservations about the semantics
> of some of the methods.  I feel like it would be beneficial to have
> more discussion before it is ready to be inserted into a Joe-E library
> which Joe-E promises to support forever.  Your choices may be fine for
> users of ref-send, but for what goes into Joe-E libraries, I think the
> question has to be about what is right for all Joe-E users.

Well, obviously it's my belief that this API will work well for all Joe-E users.

We could delay dealing with this issue for another few weeks, until I
finish making the bug fixes to the remoting library. For the ref_send
1.0 release, I only need the methods listed at the start of this
email. Are you fine with those?

> org.ref_send.list.List: I'm curious about why you named the method
> "getSize()" rather than "size()", as the latter seems to be the standard
> name used by the Java collections classes.

Bah, breaking their own naming conventions. They defined the getter
convention, and I follow it in the remoting library to determine what
methods should be invoked with a GET vs a POST. getSize() should be a
GET.

>  Have you considered making
> this implement java.util.List?

No. Disaster of an API.

>  I suspect you have and decided it was
> overkill.  Also, remind me some day to ask you why you added this class
> rather than, say, java.util.LinkedList.

Discussed earlier in this email.

> org.ref_send.promise.{curry,test}.*: I didn't look at any of this.
> (I got tired.)

Thanks for all the work.

Tyler

--

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/
Tyler Close | 4 Apr 06:42 2007
Picon

Re: Last Call for ref_send API 1.0

On 4/2/07, Dean Tribble <tribble@...> 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
Dean Tribble | 4 Apr 09:54 2007

Re: Last Call for ref_send API 1.0

On 4/3/07, Tyler Close <tyler.close-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On 4/2/07, Dean Tribble <tribble-9OagEyESeoDQT0dZR+AlfA@public.gmane.org> 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.
 
What does "Struct" here refer to?

> Closure is a very common concept that is only loosely reflected it the
> decalred interface.
Errr.. "only loosely". Please explain.
 
Closures are not generally restricted to a one argument, and generally contain a pair of a function and an environment.  This Closure reflects neither the typical closure interface (in which different closurs have different signatures) nor does it implement any typical closure behavior.  All it does is define a signature for a single-argument function (which may or may not be implemented to close over anything).  The concepts are related, but only loosely.  Delegates in C#, for example, are much closure to traditional ( e.g., Scheme) closures.  There's a fair bit of discussions about adding closure support to Java, which would add to the confusion if it ever happens.

>  I have a vague recollection that Java has an existing
> variant of Runnable that might do.
Nothing that I'm aware of.
 
I was remembering OneArgFunc from E.

> As for "Channel"...!  Just returning a struct of a Promise and a Resolver is
> a pretty measly purpose for polluting the term "Channel"!
 
I should note that my objection is as much for entertainment value as anything else.  It's plausible to refer to the Waterken communication construct as a channel.  I think it is a waste and will lead to confusion to apply it to a itiny struct that just carries a promise and resolver that actually implement a channel.  When you refer to a channel in discussion, how confusing will it be to refer to the Channel pair as opposed to the channel with interesting communication semantics?
 
Actually, I think this "Channel" corresponds well to a Joule channel.
 
Joule Channels are distinguished by their comunication semantics (partial order, cdr on receiver, etc.).  In small kernel architectures, such differences are significant.  Communications in Waterken has a fundamenally different semantics. 
 
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.
 
I'm not sure what point you are trying to make.  Linda tuple-spaces, FCP logic variables, Erlang ports are all equally similar from that level of abstraction. For such abstractions, what you cannot do is often more important than what you can do.

As for polluting the term. Joule channels don't even rate a mention on
the Wikipedia page about channels:
 
OK now you are just being mean! :)  I should it's true spend more time on self-promotion....

The org.ref_send.promise.eventual.Channel corresponds well to the
asynchronous channel documented on that Wikipedia page.
 
The waterken channel concept might.  The class as defined, however, is just a hack that Java needs because it doesn't support multiple return values.  In other languages it's entirely unecessary.  The "Channel" class provides no semantics or implementation.  If you were to follow other Java practice of having either an array or a mutable cell object representing an out arg, you would not need a class representing the pair at all.

>  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
 
...   answer.resolver.resolve(false);
 
Ah yes.  This reminds me that the pattern of having a container object has a (possibly minor) GC issue: the closure on line 55 retains a pointer to the resolver *and* the promise, even though it shouldn't need the promise.  This pattern impedes detecting dropped promises, which for example could enable various interesting optimizations in a comm system.
 
Resolvers are almost sufficient to make this problem go away.  They can be set up to single-assign their promise.  That has occasionally turned out to be convenient:
 
static public Promise<Boolean>
        and(final Eventual _, final Promise<Boolean>... condition) {
            if (0 == condition.length) { return ref(true); }
            final Resolver<Boolean> answerR = Resolver.make();
            final Promise<Boolean> answer = _.defer(answerR);
            final Slot<Integer> todo = var(condition.length );
            for (final Promise<Boolean> test : condition) {
                class AND extends Do<Boolean,Void> implements Serializable {
                    static private final long serialVersionUID = 1L;
                    public Void
                    resolve(final Boolean value) {
                        if (value) {
                            todo.put(todo.cast() - 1);
                            if (0 == todo.cast()) {
                                answerR.resolve(true);
                            }
                        } else {
                            answerR.resolve(false);
                        }
                        return null;
                    }
                    public Void
                    reject(final Exception e) {return answer.resolver.reject(e);}
                }
                _.when(test, new AND());
            }
            return answer;
        }
 
I think the above is a better psatten than the other direction:
 
            final Resolver<Boolean> answerR = _.defer();
            final Promise<Boolean> answer = answerR.promise();
 
and than what is currently there.
 
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Sandro Magi | 4 Apr 14:53 2007

Re: Last Call for ref_send API 1.0

Dean Tribble wrote:
>     > Closure is a very common concept that is only loosely reflected it the
>     > decalred interface.
>     Errr.. "only loosely". Please explain.
> 
>  
> Closures are not generally restricted to a one argument, and generally
> contain a pair of a function and an environment. 

SML functions are single-argument with multiple arguments supported via
tuples; this is more or less what ref_send does. You could define
explict tuples (Pair, Triple, ..., Nuple), but an array as in ref_send
works as well.

The environment of a closure is its private state (object's fields). So
I believe this is as close of a match as is possible in Java.

> This Closure reflects
> neither the typical closure interface (in which different closurs have
> different signatures) nor does it implement any typical closure
> behavior.  All it does is define a signature for a single-argument
> function (which may or may not be implemented to close over anything). 
> The concepts are related, but only loosely.  Delegates in C#, for
> example, are much closure to traditional ( e.g., Scheme) closures. 

Yes, C# delegates are closures, but they're only "closer" because
there's more direct compiler support/syntactic sugar:

//delegate of type Converter<int,int> for instance
int b=1;
return delegate(int a) {return a+b;}

I don't see how this is conceptually different to:

final int b=1;
return new Closure<int,int>() {
  int post(int arg) { return b + arg; } };

Adding first-class functions to an OO language generally involves
defining a distinguished interface with a single 'apply' method, which
is exactly this. I don't see why Microsoft didn't take this approach
with .NET in fact; would have simplified the concepts and the VM.

Sandro

Gmane