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

[David-Sarah Hopwood]

Tyler Close wrote:
> 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?

['_$' below is just an example of a distinguishable prefix.]

Suppose that _$post, _$get, _$when etc. were defined on Object.prototype,
and that safe Javascript subsets had the restriction that there is no
ambient authority to set or define properties with names starting '_$'.
Assume that the ref_send library is granted explicit authority to set
these properties on Object.prototype.

That would have essentially the same effect as being able to define
_$post etc. as infix operators:

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

   hits = drum._$post('bang', [ 3 ])._$get('hits');

It would still have the property that _$post always performs an
eventual send whether called on a promise or an immediate reference.
Eventual operations would be identifiable by the use of '._$'.

When not running in a subsetted language, this would be relying on
these methods not being overridden by convention, but that is only
similar to relying on (among many other assumptions) 'Q' not being
replaced.

I didn't use plain '$' for the prefix above because a property named
'$' is used in Waterken serialization. Any distinguishable prefix
for the names of eventual operators could be used, as long as Caja,
ADsafe, etc. agree on it.

The same mechanism could also work for other cases where you want
non-overridable infix operators, for example checked arithmetic.
In that case I think you'd want to reserve distinguishable prefixes
for eventual and non-eventual operators. For example, if the
restricted prefix was '_', then '_' not followed by '$' could
indicate a non-eventual, non-overridable infix operator.

-- 
David-Sarah Hopwood