Printing the constructor name for non-plain objects

[DanielSWolf]

Fixes #14

[ljharb]

What about the older engines where __proto__ isn't even available?

[DanielSWolf]

In that case, __proto__ will be undefined, as will be the result of getPrototype. Consequently, getTypeString will return null (because the result of getPrototype is falsey). And the code will behave as it always has, not printing a type prefix.

[ljharb]

Wouldn't a { __proto__: 3 } return 3 in an engine where it's not available?

[ExE-Boss]

Wouldn't a { __proto__: 3 } return 3 in an engine where it's not available?

That will happen even in engines that support __proto__.

[ljharb]

@ExE-Boss that spec text only treats it as a normal data property when it's not a string, or computed.

({ __proto__: 3 }).__proto__ === Object.prototype returns true in a modern engine, but in, say, IE 8, it returns false.

[ljharb]

Specifically, in IE 8, ({ __proto__: 3 }).__proto__ returns 3.

[ljharb]

I think you want .toString.call(o), otherwise this will always return true

[DanielSWolf]

You're right, my bad. I'll fix this.

[ljharb]

should these check that they're functions, and ideally, that they behave as expected?

[DanielSWolf]

I don't think there's anything to be gained by that. Consider that you have an object with own properties hasOwnProperty, isPrototypeOf, etc. Either this is Object.prototype, or it's an object that's trying really hard to look like it. In the latter case, chances are that all those will be functions and that they'll behave correctly.

What's the worst that can happen? The worst case is that you have an object that's trying hard to look like a plain object, and that your library prints it just like a plain object. I don't think that's bad.

After all, this library isn't generating structured information. It's generating a debug string that is supposed to help a developer understand an object graph. And I don't think that anybody will complain if something that's virtually indistinguishable from a plain object is visualized as a plain object.

[ljharb]

That's a fair point. However, to be indistinguishable, this library would have to be unable to distinguish it.

One extreme length we could go to is ensuring not just that they're all functions, but also that Function.prototype.toString.call indicates it's native code, which would work cross-realm.

[codecov]

Codecov Report

❌ Patch coverage is 70.83333% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.37%. Comparing base (7cb5c65) to head (12fdb40).
⚠️ Report is 108 commits behind head on main.

Files with missing lines	Patch %	Lines
index.js	70.83%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #15      +/-   ##
==========================================
- Coverage   98.14%   95.37%   -2.77%     
==========================================
  Files           2        2              
  Lines         216      238      +22     
  Branches       82       98      +16     
==========================================
+ Hits          212      227      +15     
- Misses          4       11       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.