toby.murray at comlab.ox.ac.uk
Thu Feb 5 12:09:11 EST 2009
On Thu, 2009-02-05 at 06:38 -0800, Tyler Close wrote:
> On Thu, Feb 5, 2009 at 2:11 AM, Toby Murray <toby.murray at comlab.ox.ac.uk> 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
> >> 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
> > 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.
> 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
> > 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
That said, I'm not sure there's a better alternative.
Thanks for the explanations. I understand the need for the changes now.
More information about the e-lang