Yehuda Katz
(ph) 718.877.1325
On Mon, Oct 15, 2012 at 9:46 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>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() {}
> }
>
> The prefix is actually more total characters in this case, but if you had
> 25 of them it would probably be easier to manage.
>
In my experiment transforming existing code, that did in fact help, but
there were still a large chunk of private name declarations at the top of
my class.
>
> 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;
> }
> }
>
Right.
> 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.
>
Or, more commonly, symbols that are used in a single class that happens to
be inside a module. Although I can't be sure about this, I expect that a
large number of modules will exist to encapsulate a single class. This is
based on my experience breaking up large JavaScript projects by modules
today, where I rarely have multiple "classes" in a single 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)
>
This is definitely a valid concern. Ruby has a similar problem via instance
variable names (which coincidentally are also `@foo`), and tries to address
this via a warning if an uninitialized instance variable is used. It's not
a particular popular warning in Ruby, fwiw.
> 2) they prevent unintended share via coincidental common name selection
>
Again, because I expect that most modules will not contain many classes, I
don't expect this to be a major issue. If the classes in a module are small
enough to justify multiple classes, it will be obvious that the same name
is reused.
That said, my original comments to this proposal addressed exactly this
issue: we might end up seeing people defensively overusing modules to wrap
classes in order to guarantee that private names don't leak out. Upon
further reflection, I don't think this is such a major issue because good
practice will lead to few classes per module anyway.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
