Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage that one.

However it is ultimately not possible to replicate because there is no
possible brand test for [[BooleanData]].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180804/33b57b2f/attachment.html>

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage those.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

Regarding cases like `Reflect.construct(Number, [], String)`, the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc. It’s not that it "considers type", but rather that these algorithms will call methods by specific names on objects they receive. String.prototype and Object.prototype both implement "valueOf", but only the former will fail the slot check.

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a special case — but the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage those.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

Regarding cases like `Reflect.construct(Number, [], String)`, the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc. It’s not that it "considers type", but rather that these algorithms will call methods by specific names on objects they receive.

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a special case — but the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage those.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

Regarding cases like `Reflect.construct(Number, [], String)`, the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc.

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a special case — but the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage that one.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

Regarding cases like `Reflect.construct(Number, [], String)`, the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc.

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a special case — but the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage that one.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

Regarding cases like `Reflect.construct(Number, [], String)`, the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate.

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a special case — but the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage that one.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a special case — but the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage that one.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].

> Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

There is no type to test. Exotic objects like Array are a different issue — the "type" of a number object is "an ordinary object with a [[NumberData]] slot". It’s really ducktyping all the way down.

Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?

Assuming the former:

The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
`instanceof` a value isn’t significant in this algorithm, just its slots
(if it is an object) or its primitive type. So one can handle number and
string by leveraging branded checks as you’ve shown — nothing more is
needed than branded methods and typeof to manage that one.

However it is ultimately not possible to (precisely) replicate because there is no
possible brand test for [[BooleanData]].