Modular At-Names

Yehuda Katz wycats at gmail.com
Tue Oct 16 06:13:21 PDT 2012


Yehuda Katz
(ph) 718.877.1325


On Mon, Oct 15, 2012 at 9:46 PM, Allen Wirfs-Brock <allen at 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. at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121016/2815675b/attachment.html>


More information about the es-discuss mailing list