Discuss
  • for-in statement: null and undefined

for-in statement: null and undefined

# Kent Hansen (16 years ago)

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.

, Kent

[1] www.ecmascript.org/license.php?file=es4-pre-release.M2.linux-x86.tar.gz [2] proposals:bug_fixes [3] es3.1:tc39-es31-draft02jul08.pdf [4] www.crockford.com/javascript/recommend.html [5] www.ecmascript.org/es4/spec/incompatibilities.pdf

# liorean (16 years ago)

On 03/07/2008, Kent Hansen <khansen at trolltech.com> 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.

# Allen Wirfs-Brock (16 years ago)

We'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.