|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
for-in statement: null and undefinedHi,
In the current public ES4 reference implementation [1], iterating over null and undefined is a no-op instead of a TypeError, which is in line with the proposal at [2] (which points out that existing web browsers already do this). However, the most recent ES3.1 draft [3] does not incorporate this change. It's not mentioned in Douglas Crockford's recommendations for modifications to ES [4] either, nor in the proposed incompatibilities [5]. So my question is, will this change be part of ES3.1 or not (doesn't it have to, for ES4 compatibility's sake)? I can't find a discussion of this issue anywhere. By the way, in the ES4 reference implementation, iterating over strings is a no-op as well; implementation bug, or are string properties not enumerable in ES4? "X".hasOwnProperty(0) returns false, too. Regards, Kent [1] http://www.ecmascript.org/license.php?file=es4-pre-release.M2.linux-x86.tar.gz [2] http://wiki.ecmascript.org/doku.php?id=proposals:bug_fixes [3] http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft02jul08.pdf [4] http://www.crockford.com/javascript/recommend.html [5] http://www.ecmascript.org/es4/spec/incompatibilities.pdf _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: for-in statement: null and undefinedOn 03/07/2008, Kent Hansen <khansen@...> wrote:
> By the way, in the ES4 reference implementation, iterating over strings > is a no-op as well; implementation bug, or are string properties not > enumerable in ES4? "X".hasOwnProperty(0) returns false, too. IIRC, this is the way it goes: A string cannot have properties itself. The temporary String object created when calling a method can have properties, but that String object is never returned from one of the ES3 (or to my knowledge ES4) methods and can thus only be returned from custom methods on the String prototype. This means that you're not likely to encounter a String object derived from a string unless you have author code that persists the temporary. The index access on a string doesn't work as property access but instead like a custom catch-all getter. > [1] > http://www.ecmascript.org/license.php?file=es4-pre-release.M2.linux-x86.tar.gz > [2] http://wiki.ecmascript.org/doku.php?id=proposals:bug_fixes > [3] > http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft02jul08.pdf > [4] http://www.crockford.com/javascript/recommend.html > [5] http://www.ecmascript.org/es4/spec/incompatibilities.pdf -- David "liorean" Andersson _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
RE: for-in statement: null and undefinedWe'll look into it for ES3.1. It sounds like it's something we've overlook that meets our criteria for changes that reflect web reality. It's possible we might want to leave the exception in for our cautious (ie strict) subset.
-----Original Message----- From: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...] On Behalf Of Kent Hansen Sent: Thursday, July 03, 2008 8:43 AM To: Es3.x-discuss@...; es4-discuss@... Subject: for-in statement: null and undefined Hi, In the current public ES4 reference implementation [1], iterating over null and undefined is a no-op instead of a TypeError, which is in line with the proposal at [2] (which points out that existing web browsers already do this). However, the most recent ES3.1 draft [3] does not incorporate this change. It's not mentioned in Douglas Crockford's recommendations for modifications to ES [4] either, nor in the proposed incompatibilities [5]. So my question is, will this change be part of ES3.1 or not (doesn't it have to, for ES4 compatibility's sake)? I can't find a discussion of this issue anywhere. By the way, in the ES4 reference implementation, iterating over strings is a no-op as well; implementation bug, or are string properties not enumerable in ES4? "X".hasOwnProperty(0) returns false, too. Regards, Kent [1] http://www.ecmascript.org/license.php?file=es4-pre-release.M2.linux-x86.tar.gz [2] http://wiki.ecmascript.org/doku.php?id=proposals:bug_fixes [3] http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft02jul08.pdf [4] http://www.crockford.com/javascript/recommend.html [5] http://www.ecmascript.org/es4/spec/incompatibilities.pdf _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
| Free Forum Powered by Nabble | Forum Help |