Modular At-Names

Herby Vojčík herby at mailbox.sk
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, 
nevertheless.

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 
consistency?

> Allen

Herby


More information about the es-discuss mailing list