Modular At-Names

Yehuda Katz wycats at
Mon Oct 15 10:35:36 PDT 2012

During the last TC39, I converted a large Ember class (Ember.View) to
ES6-style classes with private names.

I ended up needing a huge number of explicit declarations, which was very
annoying to me. At the time, I proposed making classes an implicit symbol
namespace. That didn't work because it would prevent using private names in
imperative code. Because the current class definition forces the use of
imperative code for many constructs (including static methods), this was

This approach is interesting, because it implies a 1:1 mapping between a
"privacy context" and modules. At first glance, this seems plausible, but I
don't have enough (any?) experience using ES6 modules in a real-world
context to know whether this would force the creation of many extra modules
simply to force a new namespace.

Is there any precedent we can lean on here?

Yehuda Katz
(ph) 718.877.1325

On Fri, Oct 12, 2012 at 10:51 PM, Kevin Smith <khs4473 at> wrote:

> Yes, although I don't take the "private, who needs it?" attitude as easily
>> as you do. Not saying it's wrong, but I'm not 100% convinced yet.
> In a way I'm posing a challenge - I think it will be an interesting debate
> to have.
> Doesn't this have the same problem you were arguing against in your
>> previous message, that if you want to import 37 names, you have to name
>> them all individually?
> Sure, if we were inclined to import 37 names, but I don't think that will
> be the pattern.  Look at current usage of "underscored" property names.
>  Their usage is mostly confined to a single site (usually a class).
>  Only occasionally will you find an underscored property name whose
> semantic origin is non-local (usually in class hierarchies).
> Kevin
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list