Modular At-Names

Herby Vojčík herby at
Tue Oct 16 09:50:15 PDT 2012

Allen Wirfs-Brock wrote:
> 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() {}
> }

I am not very fond of this syntax, I'd better not to have it there, 

But if I embrace it, I have a question: what about non-private symbols? 
Do they need to be explicitly declared elsewhere, but privates can be 
declared online?
IOW, shouldn't we then allow also

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

And if yes doesn't this mean it is better to use `public` instead of 
`symbol` in standalone non-private symbol declarations, as well, for the 

> Allen


More information about the es-discuss mailing list