Well, I think you’re wrong here: OrdinaryToPrimitive:
Step 5:
`methodNames` is [ “valueOf”, “toString” ]
• For each name in methodNames in List order, do
• Let method be ? Get(O, name). << `Object.prototype.valueOf,
Object.prototype.toString`
• If IsCallable(method) is true, then
• Let result be ? Call(method, O).
• If Type(result) is not Object, return result. <<
Object.prototype.valueOf returns an Object, so we continue to `toString`
> On Apr 13, 2016, at 11:19 AM, Till Schneidereit <[email protected]>
> wrote:
>
> On Wed, Apr 13, 2016 at 4:32 PM, Caitlin Potter <[email protected]>
> wrote:
> My read of section 12.8.3.1
> (https://tc39.github.io/ecma262/#sec-addition-operator-plus-runtime-semantics-evaluation),
> is that V8 is getting this right.
>
> ToPrimitive on `{}` will, by default, return “[object Object]” — We first
> call `Object.prototype.valueOf()`, which returns `this` (see 19.1.3.7).
> Following this, we call `toString()`, and get “[object Object]”.
>
> Subsequent steps of the algorithm just concatenate the two strings together.
> So it looks like the other vendors are getting this wrong?
>
> I don't think that reading is right. Steps 5 and 6 call ToPrimitive without a
> PreferredType. For objects without a @@toPrimitive property, that ends up
> calling OrdinaryToPrimitive(input, "number"), which results in NaN. So step 7
> isn't called - instead we end up running steps 8-10.
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
