A case for removing the seal/freeze/isSealed/isFrozen traps

[Brandon Benvie]

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.

On Feb 15, 2013, at 6:31 AM, medikoo <medikoo+mozilla.org at medikoo.com> wrote:

> David, that's great clarification, and indeed it looks a bit different from
> that perspective.
> 
> Still the only use case I see for freezing/sealing whole object (the way it
> works now) is when we expose some constant dictionary object on which each
> property counts, and that's very rare use case.
> I don't see much good in disallowing extensions to prototypes we expose.
> it's not JS way. We can prevent accidental modifications of *existing* API's
> but disallowing custom extensions is too restrictive and not friendly in my
> opinion.
> 
> 
> 
> 
> --
> View this message in context: http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss