var obj = {
Garrett : "monkeybrains"
,borked : "javascript" // transitivity fixed :-)
,toString : function() { return "an enumerable prop"; }
,valueOf : function() { return 2; } // also enumerable.
};

// can this be false for any value of s?
(obj.hasOwnProperty( s ) != obj.propertyIsEnumerable( s ))

Using “in” will check the prototype chain.

This feature can be useful for examining the prototype chain. For example, if you wanted to generically advise each method in a Panel
class, you could iterate through all the functions in the object’s prototype chain.
If you think about it, it can be a useful feature.

In fact, the “flaw” that Doug mentions is intentional behavior of the language. As mentioned in earlier comments, it is a perfectly valid feature (read above).

Sweeney mentioned using propertyIsEnumerable to check an object’s properties in lieu of missing hasOwnProperty.

Interestingly, propertyIsEnumerable is specified such that coforming implementations will have the exact same result as with hasOwnProperty.

Method propertyIsEnumerable does not check the prototype chain (15.2.4.7). Since all programmer-defined properties are enumerable. Therefore, propertyIsEnumerable provides the behavior that Doug so desires.

The fact that propertyIsEnumerable does not check the prototype chain is itself a bug of the spec. David Flanagan pointed this out and Brendan will readily admit that it’s a bug. JScript and SpiderMonkey both implement the spec correctly in this aspect.

The fact that propertyIsEnumerable does not check the prototype chain is, in fact, a bug that

Unfortunately, JScript suffers from another bug that causes propertyIsEnumerable to return false on a user-defined object property.

This happens when the value that is passed to propertyIsEnumerable exists in the instance and overrides a non-enumerable (DontEnum) property in the object’s prototype chain (such as an overridden “toString”)

Matthew Frank provides a tighter version of trim, and there’s nothing wrong with adding trim, however, it should be done conditionally:
if(!String.prototype.trim)
String.prototype.trim = function () {
return this.replace(/^\s+|\s+$/g, '');
};

The conditional check is necessary because future versions of ECMAScript will have String.prototype.trim.

@Andrew Dupont the !== will produce the same result as != when both operands are string values (returns false if the sequence of characters is not an exact match,). I would probably opt for != though.

Very interesting list of articles here.

But I found a bug in your last code snippet that makes the function return true for undefined variables !

var words = {
'foo' : 'foo',
'bar' : 'bar'
}
function check_word(word) {
return typeof words[word] !== 'function';
}
alert(check_word('foo')); // true
alert(check_word('foobar')); // true !!! it should be false

So here is a quick correction :

function check_word(word) {
return typeof words[word] !== 'undefined' &&
typeof words[word] !== 'function';
}
alert(check_word('foo')); // true
alert(check_word('foobar')); // false ! it's ok now


for(var key in obj) {
if(Object.prototype.hasOwnProperty.call(obj, key)) {
...
}
}


or, more compactly,


for(var key in obj) {
if({ }.hasOwnProperty.call(obj, key)) {
...
}
}


This would be familiar if you’ve seen code like


var myargs = [ ].slice.call(arguments, 2);
myfunc.apply(myobj, myargs);


Besides solving the for-in loop problem, it would be also a “cheap-chat” protected members emulation: not a bulletproof (as in any run-time compiled language) but very easy to use:
obj.secretName = someFunction;
obj.secretName.isEnumerable = false;

Dreams, dreams…