Naming convention for variable holding an eventual reference

"Tyler Close" <[email protected]>
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.