Object Initialiser not ECMAScript compliant

RESOLVED DUPLICATE of bug 219308

Status

()

--
minor
RESOLVED DUPLICATE of bug 219308
12 years ago
12 years ago

People

(Reporter: mozilla, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

If you create an object using the following syntax:

var foo = { propertyname: "somestringvalue", }

Firefox does not give a javascript error, but it should: According to Ecma-262 section 11.1.5 the correct syntax is:

Syntax
ObjectLiteral :
{ }
{ PropertyNameAndValueList }
PropertyNameAndValueList :
PropertyName : AssignmentExpression
PropertyNameAndValueList , PropertyName : AssignmentExpression

Which does not allow the trailing comma.
(ECMA spec pdf here: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf)

While this could be considered a nice feature and/or following existing programming tradition it is incorrect. Furthermore: IE6 and IE7 do give an error when using this syntax.

Reproducible: Always

Steps to Reproduce:
1. write incorrect js object initialiser
2. run in FF
3. see no error

Actual Results:  
no error was shown

Expected Results:  
Javascript Error message

'testcode'

<html> 
<head> 
<script type="text/javascript">

var foo= { propertyname: "somestringvalue" ,}

</script>
</head>
<body>                 
</body>
</html>
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

12 years ago
Thanks for filing this bug, however it is a dupe of bug 219308. In particular, see bug 219308 comment 4. 

You can get warnings for this if you set javascript.options.strict to true, and force it (and all warnings) to be an error if you set javascript.options.werror to true.

*** This bug has been marked as a duplicate of 219308 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
It is not "incorrect", it is a valid extension allowed by ECMA-262 Edition 3 Chapter 16 (first bulleted item in the second unordered list).

What's more, and why I'm commenting here: optional trailing comma will be normative in ECMA-262 Edition 4.

Please don't file misguided bugs that demand spec-only syntax when the spec explicitly allows syntactic extensions.  Edition 3 was wrong not to allow a trailing comma, and that's a bug I'm happy to report ECMA TG1 is fixing.

/be
You need to log in before you can comment on or make changes to this bug.