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

[David-Sarah Hopwood]

I wrote:
> 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 '_$'.

In other words, make these "final" methods of Object. A more general
mechanism for final methods would be of no use in ES3 because it is
untyped, so you couldn't rely on any given object being of a class/type
that defines a method as final.

[...]
> 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 '_',  [...]

A side effect of choosing '_' as the restricted prefix, BTW, would be
that code using leading '_' as a convention to indicate privacy would
fail to verify or cajole. That could be viewed as desirable, since the
leading '_' convention does not actually enforce privacy in any of
{ADsafe, Cajita, Caja, Jacaranda} (assuming that I end up using the
same convention as Caja for Jacaranda). The result would be to force,
or at least strongly encourage, the code to be changed to either:

  - use the lexical encapsulation pattern and delete the '_', or
  - in Caja or Jacaranda, use trailing '_' instead of leading '_'.

> [...] then '_' not followed by '$' could indicate a non-eventual,
 > non-overridable infix operator.

In case this wasn't clear, the checked arithmetic example would be
something like:

Object.prototype._add = function(y) { return caja.ensureNat(this + y); }

(3)._add(4);
// 7
(1e309)._add(4);
// throws exception

Still not pretty, in the absence of operator overloading, but the
arguments and operator are in the right order for people used to infix
(not for Lisp/Scheme programmers, of course). This only works if the
method is final, since the first argument object cannot in general
be trusted.

What I suggested in

   <http://www.eros-os.org/pipermail/e-lang/2004-August/009947.html>

would be prettier and a *lot* more flexible, but that would be a
significant language change. [It also extends easily to solving the
original problem discussed in this thread, by adding expansions such
as "x <- y(...) ==> Q.post(x, 'y', [...])".]

Perhaps unsurprisingly, operator overloading almost got added to ES4:

   <http://wiki.ecmascript.org/doku.php?id=proposals:operators>

but they made it unnecessarily complicated (of course), and
eventually dropped it in favour of (even more complicated) generic
functions. To get from the proposal on that page to my 2004 idea,

  - delete all of the steps that say "if the concrete class";
  - change intrinsic::op to __arithmetic.op;
  - don't include the === or !== operators, which should be primitive.

I would also define all of the comparison operators in terms of a
single 'compareTo' operator, like in E.

-- 
David-Sarah Hopwood