Implementing an identical JSON.stringify

[Michael Theriot]

>
> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and
> only if `obj` has no [[NumberData]] internal slot. Ditto for String,
> Boolean and Symbol.


I already mention this and demonstrate why it is not sufficient in my
example.

Reiterated plainly:
```js
JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
JSON.stringify(Reflect.construct(Number, [], Object)); // null
```

Even though both of these have [[NumberData]] internal slots, it also
considers the type when throwing. Hence the question if you can type check
cross-realm in a way that does not depend on internal slots.

On Sat, Aug 4, 2018 at 6:35 PM Claude Pache <claude.pache at gmail.com> wrote:

>
>
> > Le 5 août 2018 à 00:16, Michael Theriot <michael.lee.theriot at gmail.com>
> a écrit :
> >
> > `JSON.stringify` has unintuitive behavior regarding interal slots.
>
> I don’t think that anything involving an object that has a [[StringData]]
> internal slot but has `Number.prototype` in its prototype chain could have
> an ”intuitive” behaviour...
>
> >
> >
> > I think this is related to `Array.isArray`. Is there an equivalent
> `Number.isNumber`? Or is this just something only `JSON.stringify` can do?
>
> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and
> only if `obj` has no [[NumberData]] internal slot. Ditto for String,
> Boolean and Symbol.
>
> —Claude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180804/803b8dd1/attachment.html>