Re: Naming convention for variable holding an eventual reference

I believe JavaScript allows $ in names. The following are all valid 
identifiers from my tests:

var $tmp;
var tmp$;
var $tmp$;
var $t$mp$;
var tmp_$;

$ seems like a fairly recognizable symbol, particularly as a suffix.

Sandro

Tyler Close wrote:
> We have a longstanding open issue in the various object capability
> languages over how to name a variable that holds a reference that
> should only be expected to support eventual operations. The goal of
> such a convention is to communicate to the programmer that:
>     - an immediate call should not be expected to succeed
>     - in ref_send, that an operation is expected to be eventual, and
> so no side-effects will happen right away and the normal flow of
> control will continue.
> 
> The E language uses the term "rcvr" for the corresponding guard, and I
> assume as the variable name suffix. AFAICT, no one is very happy about
> it:
> 
> http://www.eros-os.org/pipermail/e-lang/2006-December/011646.html
> 
> In the ref_send library, in both Java and Javascript, the variable
> name is suffixed with '_'.
> 
> AFAIK, Caja doesn't yet have remote references and so hasn't yet faced
> this issue. It has, however, helpfully outlawed the ref_send
> convention, to MarkM's everlasting shame. ;) The Cajita subset of Caja
> also inherits this convention, though the rationale was lost as part
> of the subsetting operation.
> 
> ADsafe also doesn't yet have remote references, but the ref_send
> convention is legal.
> 
> I'm currently thinking about how to make the ref_send library play
> nicely with Caja and ADsafe and so am freshly perplexed by this
> problem. We kicked around some possibilities recently, which were a
> suffix of: "E" or "_E". I'm not terribly thrilled with either of these
> and am looking for alternatives. I suggest we test alternatives by
> applying them to the sample code at:
> 
> http://waterken.sourceforge.net/bang/
> 
> I think we are looking for either a prefix or a suffix composed of
> characters from [0-9a-zA-Z]. It's probably not ideal to use the '_'
> character due to MarkM's shenanigans. ;)
> 
> My kick at the can is a suffix of 'z', since the character kind of
> looks like the current flow of control, the top line, yielding the
> start of a later flow of control, the diagonal line down to the lower
> line. So:
> 
> var pagez = z.connect(window.location.toString()).
> var drumz = pagez.post('subject', [])
> var hitsz = drumz.get('hits')
> 
> drumz.post('bang', [ 1 ])
> 
> drumz.get('hits').when(function (value) {
>     print(value);
> }, function (reason) {
>     print('rejected: ' + reason);
> })
> 
> z.when(drumz.get('hits'), function (value) {
>     print(value);
> }, function (reason) {
>     print('rejected: ' + reason);
> })
> 
> hitsz = drumz.post('bang', [ 3 ]).get('hits')
> 
> AFAIK, there's no existing meaning for, or prohibition against, the
> use of the character 'z' in variable names. The character sequence
> "z." also still looks vaguely operator like, as "_." did. General
> meanings for the character include:
>     - compression
>     - <http://en.wikipedia.org/wiki/Z_notation>
>     - In Shakespeare's King Lear, Z is used as an insult. A character
> is called "Thou whoreson zed! Thou unnecessary letter!"
>     - Zoro's mark
>     - third axis in geometry
>     - see also <http://en.wikipedia.org/wiki/Z_%28disambiguation%29>
> 
> Alternatively, I could just bet against Caja and use the '_'
> convention for ADsafe, Javascript, Java and hope the Caja convention
> is a localized peculiarity.
> 
> --Tyler
> 
> --
> "ref_send API"
> http://waterken.sourceforge.net/javadoc/org/ref_send/promise/eventual/Eventual.html
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang