Firefox/Chrome: {} + {} etc.

Axel Rauschmayer axel at rauschma.de
Fri Jan 27 08:21:26 PST 2012


Ah! Good call. And, as expected, wrapping the first operand in parens makes the problem go away.

REPL input is tricky to parse correctly in JS, kind of between statements and expressions.


On Jan 27, 2012, at 16:56 , Bradley Meck wrote:

> Chrome and FF are treating the leading {} as an empty block statement.
> 
> On Fri, Jan 27, 2012 at 9:47 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
>> If I read ECMA-262 right then I would expect + to do the following if its operands are either {} or []:
>> 
>> - Convert each operand to a primitive via ToPrimitive()
>> - To do so, first try valueOf() (which returns an object which is thus discarded), then toString()
>> 
>> Finally, as at least one operand is a string, perform string concatenation.
>> 
>> Hence not all of the following results in Firefox look OK to me:
>> 
>>    [16:33:50.214] [] + []
>>    [16:33:50.217] ""  // OK
>>    --
>>    [16:33:56.098] {} + {}
>>    [16:33:56.099] NaN  // Not OK
>>    --
>>    [16:34:02.455] {} + []
>>    [16:34:02.456] 0  // Not OK
>>    --
>>    [16:35:38.002] [] + {}
>>    [16:35:38.004] "[object Object]"  // OK
>> 
>> Node.js is better:
>> 
>>    $ {} + {}
>>    '[object Object][object Object]'
>>    $ {} + []
>>    '[object Object]'
>> 
>> Oddly, Chrome returns the same results as Firefox (different version of V8?)

-- 
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/20120127/073646d0/attachment-0001.html>


More information about the es-discuss mailing list