Re: Bang Tutorial redux -- javascript promises

On Thu, 2009-02-05 at 06:38 -0800, Tyler Close wrote:
> On Thu, Feb 5, 2009 at 2:11 AM, Toby Murray <[email protected]> wrote:
> > On Wed, 2009-02-04 at 17:35 -0800, Tyler Close wrote:
> >> Hi all,
> >>
> >> I've been knee deep in Waterken server code for a few months now,
> >> making some changes to make it perform better and be easier to review.
> >> Anyways, I've finally gotten back to the stage where the next version
> >> is in a usable state, and so I've been working on the new Javascript
> >> interface. This version follows the ADsafe conventions and uses a
> >> different syntax. There's a test page / tutorial at:
> >>
> >> https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p
> >>
> >> I'm looking for some testing and criticism of the Javascript API.
> >>
> >
> > Looking at it quickly, I think I prefer the old syntax. How come the
> > change? What advantages does the new syntax have?
> 
> The _ convention in the previous syntax was not compatible with the
> Google coding conventions, which use a trailing _ to denote a private
> member field in an object.

Right. Fair enough.

> With the previous syntax, there was also a danger that a programmer
> would try to do an eventual operation without checking that the target
> object was actually a promise (by passing it through the _()
> function). In the current syntax, there's no way to write an eventual
> operation that is not safe: all eventual operations are invocations on
> the Q object.

I see.

> ADsafe doesn't support freezing of an object, so separate clients of
> the same promise could tamper with that promise's API, such as by
> replacing the value of the promise's "post" member. With the current
> API, it's not possible for ADsafe code to tamper with the behaviour of
> a promise.

Indeed. The lack of freezing-support is actually quite a nuisance
generally here.


> > Why the name Q?
> 
> Best we could come up with. Think of it as meaning: "This operation is
> queued for later, not done now."

Does the ref_send API expose functionality through any other interface
besides the global Q object? If not, a name that denotes the library
might be less confusing. Q is also fairly low-entropy, increasing the
chance of a collision of global variable names, although this risk is
pretty small.

That said, I'm not sure there's a better alternative.

Thanks for the explanations. I understand the need for the changes now.

Cheers

Toby