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 extensions.
Thanks! Kevin On Thu, Dec 23, 2010 at 3:18 AM, Brendan Eich <bren...@mozilla.com> wrote: > On Dec 22, 2010, at 11:58 PM, Mark S. Miller wrote: > > On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich <bren...@mozilla.com>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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
