[e-lang] Naming convention for variable holding an eventual reference

[Tyler Close]

We spent some more time kicking around this problem this morning and
finished with the following proposal.

Instead of making Javascript promises directly invokable, as in:

drum_.post('bang', [ 1 ])

we make all eventual invocations via a global object, so:

Q.post(drum, 'bang', [ 1 ])

The 'drum' reference can be either a promise or an immediate
reference; either way, the invocation is still an eventual invocation.
There's now less of a need for a naming convention for the 'drum'
variable, since it's immediately apparent that this is not an
immediate call on the referenced object; the Q object determines the
flow of control.

So the example code becomes:

var page = Q.connect(window.location.toString())
var drum = Q.post(page, 'subject', [])
var hits = Q.get(drum, 'hits')

Q.post(drum, 'bang', [ 1 ])

Q.when(Q.get(drum, 'hits'), function (value) {
   print(value);
}, function (reason) {
   print('rejected: ' + reason);
})

hits = Q.get(Q.post(drum, 'bang', [ 3 ]), 'hits')

I think the last line is the only one that presents a significant
concern. In the current syntax, it's:

hits_ = drum_.post('bang', [ 3 ]).get('hits')

On the wire, the GET request follows the POST request, which is
expressed nicely in the current syntax, but less so in the proposed
new syntax. This inversion happens to the whole chain of calls in the
statement. The effect is limited to the statement though and doesn't
cause a similar inversion in the code block.

I think the proposed syntax plays nicely in either Caja or ADsafe. The
Java ref_send API would remain unchanged.

Is this better than what we've got now? Any more improvement to be made?

--Tyler