New private names proposal

[Brendan Eich]

On Dec 22, 2010, at 6:26 AM, David Herman wrote:

> On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
> 
>> On 12/22/2010 01:02 AM, David Herman wrote:
>> 
>>>     function Point(x, y) {
>>>         private #x, #y;
>>>         this.#x = x;
>>>         this.#y = y;
>>>     }
>> 
>> I keep seeing this basic constructor example.  But isn't this the case that Oliver raised of private being over generative?  Those private names have been generated and discarded, and those two fields can never be read again...
> 
> Oops, I left out the ellipses:
> 
>     function Point(x, y) {
>         private #x, #y;
>         this.#x = x;
>         this.#y = y;
>         ...
>     }

This is for instance-private instance variables.

If you want class-private instance variables, use

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

(Allen mentioned function-own, aka static, as a way to avoid the module pattern nesting and syn-tax, but that's a separate proposal.)

I'm still sympathetic to Oliver's objection that declaration-style "private #x, #y" does not "look generative" enough. Agree that the sigil addresses Mark's concern about confusing literal identifiers with lexically bound names, at a Perlish price.

David F. mentioned script concatenation. It happens freely on the web, and it is already biting us because of premature "use strict" usage where parts of the concatenation violate strict mode and most browsers don't check yet (https://bugzilla.mozilla.org/show_bug.cgi?id=579119).

To me this is the nail in the coffin for "compilation unit private name scope". I'm with dherman: lexical scope with a declaration for bindings, but it is not clear how to make the declaration look more generative. It seems important for similar things to look alike, and different-in-generativity/etc. things to look different (somehow).

/be