rkatic (Robert Katić)

Yep, I was going to fix that: https://github.com/rkatic/jquery/commit/cff8cc4b4536012b3663a23a648b72a9ef94de67

Am I the only one perceiving problems here?

I am confused by the intention/implementation of this commit.

1) Iterating Arrays with for-in loops can produce different behaviors in older browsers. Is really length not-enumerable in every supported browser?.

2) If src is an array, and copy is a plain object, then the current implementation will do extend(true, src, copy) instead of extend(true, {}, copy).
Vice versa, if src is a plain object, and copy is an array, then the current implementation will do extend(true, src, copy) instead of extend(true, [], copy)

3) The test case at line 673 have no much sense - it do not evolving any deep extending.

kangax, thanks for clarifying which objects are "native" and which are "host". Finally it is obvious that "plain objects" are native, not built-in, objects.

When I said that "plain objects" are DEFINABLE with the literal {...} notation, then I intend that all "plain objects" can be described with a {...} notation.
Created objects with the new Object() notation can be entirely described with the {} notation.

I am conscious that an ideal implementation of isPlainObject is impossible in ES3 (probably even in ES5...), but the current one is a good compromise between accuracy and complexity. I can write several test cases that would make isPlainObject to fail, but that cases would be really unusual in real world. Currently the most slack part of the implementation is probably obj.nodeType || obj.setInterval and maybe I have a more robust (still not ideal) solution for it, but have to make some additional investigations...

And if that's the only goal, why is there a [[Class]] check in current implementation? Does it mean that besides [[Prototype]] == Object.prototype, "plain object" should also have [[Class]] == "Object"?

Well, yes.

It's still hard to explain what "plain object" really is. And the reason I'm bringing this up is that when it's hard to explain what method really does, it usually means that something went wrong and probably needs to be rethought.

Well, maybe someone can explain it better than me. John?
Even if it is not simple to explain, it is still needed to distinguish "option hashes" from other objects.
I AM of idea that it was better to avoid any need of such hard-to-define functionalities, but John probably was of idea that it is worthwhile.

Host objects can have characteristics of native objects such as Object.getPrototypeOf(obj) === Object.prototype but that is not consistent or guaranteed across browsers/environments.

Of course. It is why I used host/native as an condition of the definition.
To be more clearer, we can say that "plain objects" are all "user" objects definable with the literal {...} notation. In fact, first version of the function was named isLiteralObject. Later it was renamed to isPlainObject.

Well, we can't easily (with no surplus costs) make additionally check on obj.setInterval. Neither typeof nor isFunction() would be enough.
Is there a more robus,t but still light, way to check if an object is a Window?

Eventually we can do typeof obj.nodeType === "number", but according to the jQuery core conventions, nodes are tested with a simple obj.nodeType.

Aaaaaaaah, you and the specification have confused me. I haven't switched native/host definitions. Am I?
My English is not too good, and the ECMA specification is not always clear to me. Maybe I am not the only one...

If the whole point is that negated plain-objects are not always negative, then a simple replacement of !obj with obj == null would be enough...

1) ECMA section 4.3.8: host object - object supplied by the host environment to complete the execution environment of ECMAScript. NOTE Any object that is not native is a host object.

Seems that I switched the two definitions. Sorry guys.
However, I am not absolutely sure that native/host distinction is exact the same for all browsers. For that reason I used quotes.

So the corrected definition of "plain object" would be: Any NATIVE object obj that satisfies Object.getPrototypeOf(obj) === Object.prototype where Object is from the same window of obj.

2) I believe kangax is saying because host objects are implementation dependent, they may/may not internally provide the same GetValue(expr) results, when evaluating the not (!) operator, as that of a native object.

Since we need NATIVE objects only, I think that the not-operator is quite safe here.

3) Simple truthy checks are pretty weak, you might additionally check for the expected types of each.

IF truthy checks are still weak to you, than we can simply replace !obj with obj == null.

In theory, plain objects are all "host" objects obj that satisfies Object.getPrototypeOf(obj) === Object.prototype where Object is from the same window of obj.

1) if object type converts to false, it's not a plain object (fwiw, all native Object objects should type convert to true, but host objects can easily type convert to false);

Can you give an example?

2) if object's [[Class]] is not "Object", it's not a plain object;

Of course. Instances of other "classes" will not be considered plain objects.

3) if there's no constructor property anywhere in object or its prototype chain, it's not a plain object.

Of course. Also in IE "native" objects have not constructor property which was helpful to detect strange behavior in IE where toString.call(aNative) === [object Object]. Unfortunately it seams it was not working in the test suite, so !("constructor" in obj) was replaced with obj.nodeType || obj.setInterval.

Well, your version is faster only in the special (very rare) case of overwritted length property. In all other cases, my one was little faster.
Also you are not considering the case obj.length = new Number(N) - but yeah it is not so relevant I suppose.

Why the ^ is removed from the rtrim?