[e-lang] Naming convention for variable holding an eventual reference
Sandro Magi
naasking at higherlogics.com
Thu May 15 23:14:40 CDT 2008
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
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
More information about the e-lang
mailing list