On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson <erik.arvids...@gmail.com>wrote:
> ... and security sensitive code could just ban/alter the reflection > methods. > On Feb 15, 2013 8:29 AM, "Brandon Benvie" <bben...@mozilla.com> wrote: > >> I definitely agree that something like "preventAccidentalExtensions" >> (disallows new properties through [[Put]] but not [[DefineOwnProperty]]) >> has more common uses cases than preventExtensions, and for the precise >> reasons that David said. The security is against bugs usually, not >> attackers. PreventExtensions is a clumsy tool for managing capabilities >> because it leaves no room for giving *some* code permission while >> preventing other code, which is exactly what we want when the clueful *me* >> of now is writing code to manage the clueless *I* of the future. >> > I think this would fit a really common use case, but I would say that the current attempted way to solve this problem is private names. Last I checked, private names (or the weak map variant) would not be frozen after an Object.freeze, but only trusted parties (like methods,getters/setters, and potentially those with the shared name) could modify it. The pattern I would like to see optimized for using Object.freeze is the functional approach. I think the tools are there. Object.freeze makes immutable objects, and using Object.create to use frozen objects as prototypes, and store just the differences in the child object could potentially be an elegant way of doing persistent data structures. I haven't really tested the performance of it now, but I wonder how optimized it could get. The prototype chains could get very deep, but seeing as they would all be frozen all the way up, I wonder if it could be made more efficient. - Russ
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
