Add JS_IsPlainObject function

[harumazzz]

Used to check if an object is actually a JS object, since JS_IsObject only checked if the tag of a JSValue is JS_TAG_OBJECT.

[saghul]

Perhaps this should be called IsPlainObject?

[harumazzz]

I have changed the function name to JS_IsPlainObject now.

[saghul]

LGTM. @bnoordhuis WDYT?

[bnoordhuis]

@harumazzz what (or where) do you intend to use this? What you're doing here is very close to obj.constructor === Object but when is that useful?

[harumazzz]

In my project, I used this check for my own JSON parse/stringify and nested deep clone. There is not much case we would need this API, however since we already got JS_IsArray, I think we should also have JS_IsPlainObject?

[bnoordhuis]

What I'm trying to understand is under what conditions specifically you'd branch on JS_IsPlainObject() rather than calling e.g. JS_ToObject() and see if the conversion succeeds.

The latter corresponds to the ToObject abstract operation from the ECMA spec and is the de facto and idiomatic way of dealing with "maybe object, maybe not" values.

[harumazzz]

I think calling JS_ToObject and checking for result is rather more difficult than explicitly call JS_ToPlainObject because the additional checking, and we have to call JS_FreeValue in order to prevent memory leak. In C++, this will be a lot helpful since metaprogramming will generate objects, and reflecting plain object/class to a C/C++ struct require additional checking first, and this function perfectly suited.

[bnoordhuis]

That's not a very compelling argument. In the balance, I think it's best if we don't merge this.

On the one hand, this API is a minor addition that cannot do much harm. On the other hand, if, by your own admission, the primary use case is to skirt on writing a few extra lines of code that make for a more cohesive user experience, then it's definitely not a great API.

[chqrlie]

@harumazzz what (or where) do you intend to use this? What you're doing here is very close to obj.constructor === Object but when is that useful?

Indeed it is a weaker predicate than obj.constructor === Object.