New private names proposal

Brendan Eich brendan at
Thu Dec 23 00:18:19 PST 2010

On Dec 22, 2010, at 11:58 PM, Mark S. Miller wrote:

> On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich <brendan at> wrote:
> On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote:
> > Brendan, I still do not understand why you think it is illegitimate to consider private names and soft fields as alternatives. Do you really think we should provide syntactic support for both?
> The discussion here, including Dave's point about transposed get or set for [] being conceptually mismatched to the current [] meaning, and David-Sarah's reply about why you can't stop a third party from using your frozen object identity as the key in a weak map, have convinced me that even the frozen AST example doesn't need syntax, so much as weak maps and whatever soft fields make sense on top of them as library code.
> I do not understand this reply. Could you expand?

Dave wrote:

"[O]verloading that syntax to mean lookup in a side table is what seems like a drastic break from the intuitive model of objects. I have nothing against side tables as a programming idiom; it's when you make them look like they aren't side tables that they become confusing. Especially when you can do counter-intuitive things like add new properties to a frozen object. Of course, there are clearly use cases where you want to associate new data with a frozen object, and convenience would be helpful. I'm just not convinced that making it look like ordinary object lookup is the right programmer-interface."

David-Sarah wrote:

"What's your intended goal in preventing 'adding' fields to [a frozen] object?

If the goal is security or encapsulation, then freezing the object is sufficient. If I add the field in a side table, that does not affect your use of the object. I could do the same thing with aWeakMap.set(obj, value)."

To answer David-Sarah's question, my goal in preventing "adding" fields to a frozen object depends on the syntax used to add those soft fields in exactly this way: aWeakMap.set(obj, value) is no problem, but (per Dave's words) obj[aSoftField] = value succeeding in spite of obj being frozen *is* a problem, conceptually for teachers, learners, documenters, hackers -- everyone building a mental model of "objects and properties" including freezing.

It seems you agree enough to be exploring @ instead of ., which could desugar to transposed .get or .set. So perhaps more new syntax will help, rather than less new syntax and too much overloading of old.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list