On 15 January 2013 17:16, Kevin Smith <khs4...@gmail.com> wrote: > >> It's really none of your business when you try to freeze my object whether >> any of >> >> (a) pre-existing private-symbol-named properties remain writable; >> (b) weakmap-encoded private state remains writable; >> (c) objects-as-closures environment variables remain writable. >> >> Really. Not. Your. Business! > > > But that's a change from the current object model and by (a) you're assuming > the conclusion. ES has a really simple object model, as explained in the > first part of the ES5 specification. That simplicity is an advantage. If > you're going add complexity, then it should be justified with > application-focused use cases. That request does not seem like a stretch to > me.
Just to throw in one more opinion, I sympathise with Kevin to some extent. Despite Sam's argument, I think there is considerable complexity imposed by private names, and it has been increasingly unclear to me that it is really warranted at this point. It might be worth reconsidering and/or post-poning, and Kevin made a few good arguments to that end later down the thread. (However, I don't follow your description of the ES5 object model being "really simple". With sufficient squinting, you may call the ES3 model (relatively) simple, but ES5 certainly put an end to that. Now, ES6 is adding several whole new dimensions of complexity, all of which dwarf private symbols. Let alone a potential Object.observe in ES7. In fact, there are very few languages that have an object model more complicated than that. ;) ) /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
