Closed
Bug 356131
Opened 18 years ago
Closed 18 years ago
Object Initialiser not ECMAScript compliant
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 219308
People
(Reporter: mozilla, Unassigned)
Details
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>
|
||
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 1•18 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
Closed: 18 years ago
Resolution: --- → DUPLICATE
|
||
Comment 2•18 years ago
|
||
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.
Description
•