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.@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
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
