New private names proposal

Kevin Smith khs4473 at
Thu Dec 23 05:53:05 PST 2010

If I might ask a side-question:  what's the value in making an object
non-extensible in ES5?  I understand the value of making properties
non-configurable or non-writable, but I don't yet see a reason to prevent


On Thu, Dec 23, 2010 at 3:18 AM, Brendan Eich <brendan at> wrote:

> 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.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list