Discuss
  • Name syntax

Name syntax

# David-Sarah Hopwood (15 years ago)

On 2010-12-23 16:36, thaddee yann tyl wrote:

The private names proposal has a lot of good ideas, but their use is not obvious. The reasons I see for that are: The "private a;" declaration:

  • changes meaning of all obj.a in scope
  • looks like a scoped variable, not a private element of an object
  • is not generative-looking ... which makes it harder to understand, and use.

I agree with these criticisms.

I find that David Herman's proposal fixes those issues:

But your idea suggests yet another alternative worth adding to our growing pantheon. We could allow for the scoping of private names, but always require them to be prefixed by the sigil. This way there's no possibility of mixing up public and private names. So to use an earlier example from this thread (originally suggested to me by Allen):

function Point(x, y) { private #x, #y; this.#x = x; this.#y = y; }

I understand that the number sign gets really heavy and annoying after some time. As a result, I suggest a simpler syntax, "private .secret;":

[...]

private .a; k..a = o;

I find this less readable, and I think it would be easy to miss the difference between . and .. in larger expressions. Also, the .. operator is used in other languages for ranges.

In any case, let's not bikeshed about this yet. Either .# or @ is fine for discussion. ('.#' is perhaps more suited to being viewed as a variant of '.' with a private field selector, and '@' as an operator distinct from '.')

# David-Sarah Hopwood (15 years ago)

On 2010-12-23 20:44, Brendan Eich wrote:

On Dec 23, 2010, at 11:59 AM, Dmitry A. Soshnikov wrote:

On 23.12.2010 22:39, Brendan Eich wrote:

The .. is wanted by other extensions, and already used by ECMA-357 (E4X), FWIW.

JFTR: and also in ECMA-262:

1..toString()

Yes, although if we added any .. as in Ruby or CoffeeScript it would, by the maximal munch principle, be tokenized instead of two dots.

You'd actually have to also change the StrUnsignedDecimalLiteral production, since that "munches" the first dot before the '..' is tokenized. Anyway, the use of '..' in E4X and as a range operator in other languages is sufficient reason not to use it here.