Modular At-Names

Allen Wirfs-Brock allen at
Mon Oct 15 18:46:03 PDT 2012

On Oct 15, 2012, at 6:02 PM, Brendan Eich wrote:

> Axel Rauschmayer wrote:
>> One thing to consider: I would expect IDEs to help with this. For example, Eclipse does a pretty good job of letting one forget that one has to import things before one can use them.
> Maybe, but forget IDEs. I think Kevin's point about private @foo, @bar, ...; being required in a class using those 25 private members will get old, fast.

But if you want private symbols you are going to have to say something anyway to distinguish them from regular "public" unique name symbols.

At the last TC39 meeting, I believe we agreed that I should expand the private name syntax proposal to include allowing private as a prefix to concise methods.  So you could say:

class Foo {
  private @x() {}
  private @y() {}

as an alternative to:

class Foo {
  private @x, @y;
  @x() {}
  @y() {}

The prefix is actually more total characters in this case, but if you had 25 of them it would probably be easier to manage.

If you are using private symbols for per instance state you need to be explicit about it so it can be referenced byboth method bodies and the constructor:

class Foo {
    private @state;
    get state() {return @state};
    set state((value) {@state = value}
    constructor (initialState) {
       this. at state = initialState;
If at the module level, you are defining a set of "public" symbols that will be exported so they can be used as names in public interfaces you need to be explicit about the export:

module M {
   export symbol @a, @b, @c, @d
   export class Foo {
       @a() {};
       @b() {}

So, it seems like the only time when you might get away without explicit symbols declarations would be for module local "public" symbols that are shared among multiple classes defined within the module.

> The module vs. let scope is also interesting. Allen said the literature favored the latter but that wasn't clear from my nowhere-near-comprehensive reading.

Presumably that is a large part of our motivation for providing lexically scoped let/const/function/class rather than the semi-global function scoping. 

I believe the main arguments against implicit  declarations are:
   1) they catch misspelling inconsistencies (but not consistent misspellings)
   2) they prevent unintended share via coincidental common name selection


More information about the es-discuss mailing list