Javascript's IN Operator Does Not Work With Strings

Why not just test if ( typeof arg === 'string' ) { ... } ?

I tried this.

var n = 1.2;
alert('length of n = ' + ('length' in n));

I also generates:
invalid 'in' operand n
[Break on this error] console.log('length of n = ' + ('length' in n));

I suppose scalar type (other than object inherited type) always has such problem.

There is a difference between string primitives and String objects in Javascript.

When you change the line
var stringValue = "";
to
var stringValue = new String("");

it will work as expected. Javascript is weird ;)

String primitives and String objects give also different results when using the eval function.

Really really :)
Take a look at this (especially the evaluation examples)
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/String

From my understanding it temporarily converts a string literal to a String object if you try to call a member function of String (either inherited or core).
But since IN is an operator and technically no member function, there is no convertion.

Anyway, I too find it confusing to have string primitives and objects coexist. Especially because they act the same most of the time due to the implicit conversion.

Glad I could help a bit, because I've already learned so much from you. In fact your jQuery presentation (ca. 1.5 years ago) was my first contact with jQuery and Javascript. Big Thanks :-)

The next iteration of JS is supposed to finally get rid of the string primitive problem. Martin is right that the problem is that "in" is an operator and not a method.

"foo" in new String("bar") does work for that reason.

I'm pretty sure all this nonsense came about for performance reasons back inside the NS4 code base. Shame we still live with it today. :/

In my experience, a "for (... in ...)" loop on a string iterates over the characters of the string.

So I just now ran this experiment:

$(document).ready(function()
{
var sName = "";
var sString = "lit";
for (sName in sString)
alert("sString[" + sName + "] = '" + sString[sName] + "'.");
sString = new String("new");
for (sName in sString)
alert("sString[" + sName + "] = '" + sString[sName] + "'.");
});

In Firefox 3.6.3, Google Chrome 4.1, Netscape 8.1, Opera 10.53 and Safari 4.0.5, I got just an iteration over the characters in both strings. No length property. In MSIE 7, I got nothing at all.

I can try it again on my Mac when I get home, if you like.

@Ben

NS4 = Netscape 4. The birthplace of modern javascript.

@Ben:

My point was not to show something cool, but rather to reveal more about the nature of "in (string)". Specifically, length doesn't show up in the loop on any browser so far.

I just now looked through the PDFs of the 3rd and 5th editions of the standard (from ecmascript.org), and it seems that properties can have properties. One of them is whether or not a property is enumerable, which is what affects the in operator.

It was freaky enough, once upon a time, to learn that methods can have methods. Now I've got to wrap my head around properties having properties.

Of course, It's easy to think of implementation-defined properties of properties. For example, in the DOM, window.location has window.location.href.

I meant LANGUAGE-defined IMPLICIT properties, like the language-defined implicit methods .call() and .apply() that all functions have.

Apparently there's this whole underbelly of language-defined properties that properties have, but we don't know they have them, because they're not enumerable, including the enumerable property itself.

Here's an interesting question: Does a function's .call() method have its own .call() and .apply methods? The answer is yes, they do, in every browser I've tried. That means that they can't possibly exist until they're referenced, or else the first time you define a function would cause an infinite loop.

And here's another interesting question: If you do functionname.call(object1).call(object2), which object becomes this? The answer to that one is consistent across browsers too.

Ohh, what's really going to bake your noodle later on is, would you still have called it if I hadn't said anything?

@Ben: I just finished reading Douglas Crockford's book Javascript: The Good Parts. Appendix A is The Awful Parts, and one of those is "Phony Arrays".

Turns out, JavaScript arrays are simulations based on object properties that just happen to be non-negative integers. Many of the things we think of as arrays are not even descended from Array, such as arguments[...] within a function.

For my 2¢, I think of something as a JavaScript Array object if it has a length property and all of the methods I've come to associate with Arrays, such as join(), push(), sort(), etc. The way to test that, from both jQuery 1.4.2's isArray() and Crockford's book, is Object.prototype.toString.call(obj) === "[object Array]". You can also do that to detect Strings with "[object String]". You can also use apply() instead of call(), because toString() doesn't take any arguments.

So, it turns out, the call() method of every Function object, but in particular, of toString(), actually is a way to detect whether an object truly is an Array. No need for "in".

@Ben: One more thing... JavaScript: The Good Parts answers your original observation, that "in" doesn't work with strings. Quoting Chapter 3 "Objects", first paragraph:

<ul>
"The simple types of JavaScript are numbers, strings, booleans (true and false), null and undefined. All other values are objects. Numbers, strings and booleans are object-like in that they have methods, but they are immutable. Objects in JavaScript are mutable keyed collections. ..." [bold emphasis added]
</ul>

In your example code at top of page, you wrapped 1 in an object wrapper with numberValue = new Number ( 1 ), but you didn't do that with stringValue. If you had defined string value as new String ( "" ) instead, "length" in stringValue would have returned true. I know this, because I just tested it in Firefox and MSIE and got true in both.

So the problem was that you said "length" in simpletype, not "length" in objecttype. So it WAS an invalid operand.

Don't feel bad. I've been doing JavaScript since it was called LiveScript (and was case-insensitive, believe it or not), and I didn't realize this about strings either.

P.S.: Put that together with my previous observation (that Object.prototype.toString.call(obj) === "[object String]" can be used to detect strings), and you see that Object.toString() lies in all browsers. String is not an object unless you wrap it in an object wrapper with new String().

It could very well be that the initialization code of Object.prototype.toString() casts the operand into an object, so that it can call internal methods that it wouldn't otherwise be able to call. In other words, toString() might not have been lying, per se, but rather, was being not as precise as we would like.

It really ought to have returned "[value String]" or "[simpletype String]".

I'm surprised no one else has explained this more clearly, though most of the pieces are scattered throughout the comments.

I'm going to start by poking some holes in your tests, and also point out some JavaScript quirks you probably haven't noticed, which I hope will motivate my excruciatingly detailed (but hopefully painfully clear) explanation.

Firstly, if instead of

var stringValue = "";

you had tried

var stringValue = new String( "" );

then

in

would've worked fine and returned

true

.

Secondly, if instead of

var numberValue = new Number( 1 );

you had tried

var numberValue = 1;

then you would have gotten the TypeError when you tried

console.log( "Number", ("length" in numberValue) );

Thirdly, if instead of trying

console.log( "Boolean", ("length" in true) );

or however you had tried testing boolean values, you had done

console.log( "Boolean", ("length" in new Boolean( true ) ) );

it would in fact have worked and returned

false

.

Fourthly, I wonder why

in

doesn't work on

null

or

undefined

, either?

Fifthly, guess what value gets logged if you try

var numberValue = 1;
numberValue.someProp = 'prop';
console.log( numberValue.someProp ); //=> undefined

versus trying

var numberValue = new Number( 1 );
numberValue.someProp = 'prop';
console.log( numberValue.someProp ); //=> "prop"

I'm sure by now you notice a pattern in what works as expected and what doesn't. Well, don't get ahead of yourself, have you ever tried

console.log( typeof 1 ); //=> "number"
console.log( typeof "" ); //=> "string"
console.log( typeof true ); //=> "boolean"
console.log( typeof false ); //=> "boolean"
console.log( "Everything's as expected, what's up with the next ones though?" );
console.log( typeof new Number( 1 ) ); //=> "object"
console.log( typeof new String( "" ) ); //=> "object"
console.log( typeof new Boolean( true ) ); //=> "object"
console.log( typeof new Boolean( false ) ); //=> "object"

Starting to get the picture?

One of the shortcomings JavaScript borrowed from Java was the distinction between primitive types and the object type.
Number values, like 1,
string values, like "",
the boolean values true and false,
and the special values null and undefined
all have primitive types,
while all other kinds of values, including the builtin
Date objects,
regular expression objects,
function objects,
arrays
and literal objects like {},
all have the object type.

What's the difference between primitive types and the object types? Plenty, the one you're noticing here being that the

in

operator only works on objects, but the main one is that you can access and assign properties of objects, whereas primitive values are just naked values.

But wait, you say, I've totally done

'primitive-valued string literal'.split(' ')

before, where I'm accessing the

split

property of the string, which I expect to be a function, and then call that function (such properties which hold function values are also called methods) !

Really? You think you're accessing the

split

property of that string value? Explain this:

var str = 'primitive-valued string literal';
console.log( str.split(' ') ); //=> obviously ["primitive-valued", "string", "literal"]
str.split = function(){ return 'overridden!'; };
console.log( str.split(' ') ); //=> still ["primitive-valued", "string", "literal"]

Wait a minute...

var str = new String( 'primitive-valued string literal' );
console.log( str.split(' ') ); //=> obviously ["primitive-valued", "string", "literal"]
str.split = function(){ return 'overridden!'; };
console.log( str.split(' ') ); //=> still ["primitive-valued", "string", "literal"]

In Java, this feature is called auto-boxing. Whenever you access or assign to a property of a number, string or boolean, a temporary object value (of the Number, String or Boolean class, respectively) is created with the same naked value as the primitive value, but that temporary object is only available to that property access, and does not replace the primitive value that your variable references.

I hope that makes perfect sense now. Elsewise, this next part will be even more confusing.

Unlike number, string or boolean values, the other two primitive values,

null

and

undefined

aren't auto-boxed. That is why, not only does

in

through a TypeError on them, but any property access or assignment on a

null

or

undefined

value will through a TypeError.

But that's merely annoying. Here's something that's downright wrong:

console.log( typeof undefined ); //=> "undefined", no surprise there
console.log( typeof null ); //=> "object" wait what?

The null value absolutely has a primitive type, as you can see for yourself that assigning or accessing a property of a null value throws a TypeError, as does

in

. Even the ECMAScript 3 spec says it has a primitive type--it's own special null type, in fact. But when describing the

typeof

operator, it has a special exception for

null

, simply because this was already the case in pre-existing widespread implementations of ECMAScript 3 (that would be NS4).

If there's anything in my explanation that could be further clarified, please let me know.

I have one last request: I admire your impulse to experiment and test, which is very important, but reading the documentation is important, too. Your blog has pretty high Google rankings, so I've come across it when looking up JS quirks before, and I believe that like w3schools.com, you have some small responsibility to provide accurate information. But every time I've come across your blog, it's been clear you didn't check the ECMAScript 3 spec and your conclusions about how stuff works are just wild guesses based on limited tests, and since of course you don't blog about obvious, expected behavior, your blog posts are about subtle, confusing quirks, so your understanding has invariably been flawed, just like this. So next time you run some tests and come up with "I am not sure why this is the case", I urge you, maybe try reading the documentation.

tl;dr: RTFM, my friend

@Han,

Damnit, typos, should be:

Wait a minute...

var str = new String( 'primitive-valued string literal' );
console.log( str.split(' ') ); //=> obviously ["primitive-valued", "string", "literal"]
str.split = function(){ return 'overridden!'; };
console.log( str.split(' ') ); //=> "overridden!" that's more like it

Also, didn't expect all my &lt;code/&gt; blocks to be made display:block, usually they're just font-family: monospace but still display:inline. Oh well, still mostly readable.

I am almost positive the reason this does not work is because of the way JavaScript uses string objects as wrappers. When you call a method of a string, it passes it to new String() and calls the method on that newly generate object. Once that object is done with, it deletes it. Try calling it like this "length" in new String(stringValue). Remember strings are not objects until they are conveyed to be.

Please copy and paste the following script in your JavaScript console:

(function(undefined) {
	var i, v = [
		undefined, void(0),
		null,
		false,
		0, NaN, -1/0, 1/0,
		'0',
		[],
		{}, new (function(){})(),
		new Date(),
		function() {}
	];
 
	function whatis(v) {
		var ops = Object.prototype.toString;
		if (undefined === v || null === v) {
			return v + '';
		}
		return ops.call(v);
	}
 
	for (i = 0; i < v.length; i++) {
		console.log(whatis(v[i]), ' | ', 'length' in Object(v[i]));
	}
})();

Just my two cents.

Well, it's pretty simple, actually. Consistent results come out of consistent data.

You are initialising your sting as a primitive value and your number as an object. Native values don't have properties and in particular they don't have the method 'in'.

To have normalised data you can compare you need to either initialise your string as

var stringValue = new String("");

or initialise your number value as

var numberValue = 1;