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

[Axel Rauschmayer]

I like this direction: it would distinguish the user-level operation _assignment_ from the meta-level operation _definition_. I’m not sure where `delete` fits in, but it’s much less common, so less of a potential problem.

On Feb 15, 2013, at 11:03 , Mariusz Nowak <medikoo+mozilla.org at medikoo.com> wrote:

> 
> I've worked a lot with ECMAScript5 features in last two years, and I must say
> I never found a good use case for Object.freeze/seal/preventExtensions, it
> actually raised more issues than it actually helped (those few times when I
> decided to use it). Currently I think that's not JavaScript'y approach and
> use cases mentioning "untrusted parties" sounds "logical" just in theory, in
> practice when actually we never include "untrusted" modules in our code base
> does not make much sense.
> 
> However, main point I want to raise is that several times I had a use case
> for very close functionality, that with current API seem not possible: 
> I'd like to be able to *prevent accidental object extensions*. I want to
> control all enumerable properties of the object, so they can only be set via
> defineProperty, but any direct assignment of non existing prop e.g.
> 'x.notDefinedYet = value'  will throw. Imagine some ORM implementation, that
> via setters propagates changes to underlying persistent layer, at this time
> we cannot prevent accidental property sets that may occur before property
> was actually defined (therefore not caught by the setter)
> I assume that proxies will make such functionality possible, but maybe some
> Object.preventUndefinedExtensions will be even better.

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130215/842c6997/attachment-0001.html>