Object.seal, read references, and code reliability

[Don Griffin]

<imho>Land mines like this are bad for JS. Reads should always be safe to
do as in "foo && foo.bar". Throwing errors from that is always bad.
duck-typing, feature detection etc are all valid uses for objects ... even
sealed/frozen/locked/obfuscated ones :) </imho>

Just give me "undefined" on reads like these. I would much rather have that
and possibly Object.isFrozen/isLocked/isSealed etc methods to test these
conditions if appropriate.


Best,
Don
--
Don Griffin
Sr Director of Engineering
Sencha, Inc.
https://www.sencha.com/

On Mon, Aug 14, 2017 at 1:44 PM, Oriol _ <oriol-bugzilla at hotmail.com> wrote:

> > Why do you think `[[Get]]` needs a flag? The object will have the flag
> on it, and `[[Get]]` has the object.
>
> I also think a new flag or something similar is needed, because it would
> be good to throw if some object in the prototype chain is locked, not
> necessarily the receiver.
> I would expect this:
>
> ```js
> let locked = Object.lock({});
> let inherits = Object.create(locked);
> Reflect.get(locked, "foo"); // TypeError
> Reflect.get(locked, "foo", {}); // TypeError
> Reflect.get({}, "foo", locked); // undefined
> Reflect.get(inherits, "foo"); // TypeError
> ```
>
> -Oriol
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170814/0516f6e6/attachment.html>