A case for removing the seal/freeze/isSealed/isFrozen traps
russell.leggett at gmail.com
Fri Feb 15 06:35:40 PST 2013
On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:
> ... and security sensitive code could just ban/alter the reflection
> On Feb 15, 2013 8:29 AM, "Brandon Benvie" <bbenvie at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss