util: use @@toStringTag in util.inspect #16956

devsnek · 2017-11-11T16:36:58Z

Uses @@toStringTag before constructor.name which yields names where there previously weren't or more correct names.

closes #16952

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
docs changes included
tests and/or benchmarks are included
commit message follows commit guidelines

Affected core subsystem(s)

util

refack

Code LGTM but this needs a test.

refack · 2017-11-11T17:09:06Z

@devsnek thank you for the contribution!

TimothyGu · 2017-11-11T18:02:18Z

lib/util.js

+
+  // try to use @@toStringTag, fall back to constructor name, empty string
+  let tag = '';
+  if (hasOwnProperty(value, Symbol.toStringTag)) {


@@toStringTag is inherited. E.g. Object.prototype.toString.call(new Date()) returns [object Date], even though new Date().hasOwnProperty(Symbol.toStringTag) is false. IMO the check for @@toStringTag should be folded into a part of getConstructorOf and searched at the same time by walking the prototype chain (of course, then getConstructorOf would have to be modified to return a string instead).

how about getIdentifiableTagOf

addaleax · 2017-11-11T21:39:45Z

I'm pretty sure I would prefer the constructor name to take precedence over @@toStringTag .. the constructor is at least as specific as the tag, plus this works well with subclasses

mscdex

-1 The name before the braces should be a class/constructor name, not anything else, for consistency.

addaleax · 2017-11-12T01:01:22Z

@mscdex if you're worried about consistency, would it help to modify how the tag I'd displayed? Eg in braces or sth like that?

TimothyGu · 2017-11-12T01:30:43Z

@mscdex

-1 The name before the braces should be a class/constructor name, not anything else, for consistency.

Symbol.toStringTag is used as class/constructor name by the ECMAScript spec itself, for consistency and compatibility with earlier versions of ES through Object.prototype.toString. So should we.

jasnell · 2017-11-12T01:33:58Z

It would be semver-major, but perhaps there is a way to show both.

Given the example

class Foo {
  constructor() {}
  get [Symbol.toStringTag]() { return 'bar' }
}

const f = new Foo();
util.inspect(f)

The current result is Foo { } ... we could make it ... [Foo bar] { } or Foo [bar] { } to include the @@toStringTag value.

devsnek · 2017-11-12T01:41:36Z

Foo:bar { }? [Foo bar] would he the most consistent with how Object.prototype.toString works

addaleax · 2017-11-12T01:43:23Z

I like Foo [bar] {}, with [bar] {} being used when no constructor name is present and Foo {} when no toStringTag is present?

jasnell · 2017-11-12T01:47:10Z

Works for me.

devsnek · 2017-11-12T02:00:30Z

will do 👍

devsnek · 2017-11-12T03:29:49Z

are people ok with this producing things like Object [WebAssembly]?

addaleax

Mostly LGTM, thanks for the work!

addaleax · 2017-11-12T14:33:26Z

lib/internal/util.js

@@ -203,6 +203,41 @@ function getConstructorOf(obj) {
  return null;
 }

+function getIdentifiableTagOf(obj) {
+  let namespace = '';


namespace? Why not call it constructor?

addaleax · 2017-11-12T14:33:27Z

lib/internal/util.js

+        if (desc.value !== undefined)
+          tag = desc.value;
+        else if (desc.get !== undefined)
+          tag = desc.get();


get() should be called with the this object being set to the original value of obj… right now this would refer to the descriptor object

Oh, and also maybe wrap this in a try { … } catch, we don’t really know what the getter will be doing

if it throws why wouldn't we want that to bubble up to the user?

addaleax · 2017-11-12T14:34:18Z

lib/internal/util.js

+  if (namespace === tag)
+    return namespace;
+
+  return `${namespace} ${tag ? `[${tag}]` : ''}`.trim();


Why the .trim()?

addaleax · 2017-11-12T14:36:46Z

test/parallel/test-util-inspect.js

+// @@toStringTag
+assert.strictEqual(util.inspect({ [Symbol.toStringTag]: 'a' }),
+                   'Object [a] { [Symbol(Symbol.toStringTag)]: \'a\' }');
+


Can you add a test like this?

class Foo { constructor() { this.foo = 'bar'; } get [Symbol.toStringTag]() { return this.foo; } } assert.strictEqual(util.inspect(new Foo()), 'Foo [bar] { foo: \'bar\' }'));

To be clear, I don’t think this is a good way to write a class, but it should work :)

joyeecheung · 2017-11-12T15:51:13Z

If we are adding a new syntax, maybe we should explain it in the docs because one might not be able to immediately tell what Foo and bar in Foo [bar] {} represent just by looking at it..

addaleax · 2017-11-12T17:09:53Z

@refack @TimothyGu @mscdex PTAL

jasnell · 2017-11-12T18:06:05Z

doc/api/util.md

@@ -330,6 +330,18 @@ changes:
 The `util.inspect()` method returns a string representation of `object` that is
 primarily useful for debugging. Additional `options` may be passed that alter
 certain aspects of the formatted string.
+`util.inspect()` will use the constructor's name and `@@toStringTag` to make an


Nit: blank line before this to start the new paragraph.

jasnell · 2017-11-12T18:12:03Z

doc/api/util.md

+}
+
+util.inspect(new Foo); // 'Foo [bar] {}'
+```


I would also add some detail on what happens if @@toStringTag and construtor name are not present... e.g.

`util.inspect()` will use the constructor's name and `@@toStringTag` (if present) to make an identifiable tag for an inspected value:

Then the examples:

class Foo { get [Symbol.toStringTag]() { return 'bar'; } } util.inspect(new Foo()); // 'Foo [bar] {}`

function foo() { return new (class { get [Symbol.toStringTag]() { return 'bar'; } }); } util.inspect(foo()); // '[bar] {}`

class Foo {} util.inspect(new Foo()); // 'Foo {}`

that second one would actually be Object [bar] {}, ~~i'm not sure that constructor name will ever be absent.~~

Object.create(null, { [Symbol.toStringTag]: { value: 'hi' } })

> function m() { ... return new (class {}) ... } undefined > m() {} > m().constructor.name '' >

> new (class {}) {} > new (class { get [Symbol.toStringTag]() { return 'tst'; } }) Object [tst] {}

not exactly sure whats going on here but it looks like if the class is empty the inheritance from Object is optimised away?

In any case i think Object.create is a really good way to show that the inspected value has no constructor

mscdex · 2017-11-12T21:09:08Z

doc/api/util.md

+
+class Bar {}
+
+const Baz = Object.create(null, { [Symbol.toStringTag]: { value: 'foo' } });


s/Baz/baz since it's not a constructor

mscdex · 2017-11-12T21:09:55Z

doc/api/util.md

+
+const Baz = Object.create(null, { [Symbol.toStringTag]: { value: 'foo' } });
+
+util.inspect(new Foo); // 'Foo [bar] {}'


I think it's better to keep the parentheses after the constructor name, here and on the line below.

mscdex · 2017-11-12T21:11:50Z

As far as the current layout/display goes, I guess it's ok for now, definitely much better than the original.

mscdex · 2017-11-13T01:23:23Z

lib/internal/util.js

+  if (constructor === tag)
+    return constructor;
+
+  return `${constructor} ${tag ? `[${tag}]` : ''}`.trim();


I think we could instead just branch on tag to avoid the trim(). Something like:

if (tag) return `${constructor} [${tag}]`; return constructor;

mscdex · 2017-11-13T01:28:07Z

lib/util.js

  if (ctx.seen.indexOf(value) !== -1)
    return ctx.stylize('[Circular]', 'special');

  if (recurseTimes != null) {
    if (recurseTimes < 0)
-      return ctx.stylize(`[${constructor ? constructor.name : 'Object'}]`,
-                         'special');
+      return ctx.stylize(`[${tag.trim() || 'Object'}]`, 'special');


We could avoid trim() here if we saved the original getIdentifiableTagOf() result. Maybe change the current tag variable to prefix or something to differentiate between the two?

refack · 2017-11-15T21:05:29Z

I agree that if this was only util.inspect that this would have been an exception, but since console.log is wired to use util.inspect IMHO it escalates the impact of this change. Using console.log is ubiquitous, and it's not just debugging.

(Simplest use-case I can think of is a test case that checks process output against a static fixture. If somewhere it outputs an iterator, after this change it will fail.)

BTW: this is actually diverging from chrome:

node after this change:

> class subm extends Map {}
undefined
> console.log(new subm().keys())
[Map Iterator] {  }
undefined
> console.log(new subm())
subm [Map] {}
undefined

refack · 2017-11-15T21:09:17Z

P.S. if we flag util.inspect to keep the old behavior when called from console.log I agree this is minor.

devsnek · 2017-11-15T21:32:17Z

I would agree that console.log doesn't need all this. i just wanted this for repl

addaleax · 2017-11-15T21:36:27Z

I don’t think letting console.log and util.inspect diverge is a good idea. I’d rather have this be semver-major than jumping to that…

TimothyGu · 2017-11-15T21:37:50Z

@refack Using console.log on anything but a primitive is ambiguous by default, and in my opinion leaves significant leeway to what we can output for objects. For a standardized, structured, and parsable output one should always use something like JSON.stringify. And for the comparison to DevTools -- as long as we are showing at least as much information as DevTools, I would be entirely fine with not showing exactly what DevTools does.

Thought: if constructor.name is not available, use @@toStringTag as the constructor name without any additional indication. This would make new Map().keys() emit Map Iterator {} rather than [Map Iterator] {}, similar to Firefox. MapIterator (what DevTools shows) has no basis in the ES spec.

addaleax · 2017-11-15T21:44:51Z

@TimothyGu As I understand it, both @mscdex and me are -1 on that – showing something that may or may not be a constructor name seems to introduce inconsistency without any need for it…

devsnek · 2017-11-15T21:45:53Z

as long as we are showing at least as much information as DevTools, I would be entirely fine with not showing exactly what DevTools does.

+1

@TimothyGu

if constructor.name is not available, use @@toStringTag as the constructor name without any additional indication.

I was considering this but i think keeping it distinct is the best option so that when debugging people know where the names are coming from.

refack · 2017-11-15T22:04:18Z

Using console.log on anything but a primitive is ambiguous by default, and in my opinion leaves significant leeway to what we can output for objects. For a standardized, structured, and parsable output one should always use something like JSON.stringify. And for the comparison to DevTools -- as long as we are showing at least as much information as DevTools, I would be entirely fine with not showing exactly what DevTools does.

I agree with both statements (log ambiguity, and DevTools!=standard), but in terms of risk/reward IMHO this feature is not worth the risk. It's just my gut feeling, as I don't know what kind of code is out there. I'm not strongly opposed to this landing as non-major, but I'd advise against it.
BTW If we land this as major it'll be available in the nightly build for use as an exploratory REPL tool.

evanlucas · 2017-11-16T00:14:44Z

I think this should be semver-major. If we are going to be able to change the output of a stable api in a minor/patch version, we should explicitly state "Do not rely on the output of this. It can and will change." in the documentation. Or at least something along those lines. Just because we state that the primary purpose of the api is for debugging doesn't mean it's used that way in practice.

addaleax · 2017-11-28T01:14:31Z

@devsnek Could you put 6cc4b5e in a separate PR? We might need more discussion around that change on its own, and I would really like the original changes in here to get merged.

Also, I'm not sure what that last commit does? We can probably just drop it? We don't usually do merge commits, they break CI because that rebases automatically..

devsnek · 2017-11-28T03:50:44Z

er its just a regular merge? i can squash my commits if you want, i had to merge it because there was a conflict

TimothyGu · 2017-11-28T18:08:50Z

i had to merge it because there was a conflict

Please rebase instead.

uses @@toStringTag when creating the "tag" for an inspected value

addaleax · 2017-11-30T02:05:32Z

Fresh CI: https://ci.nodejs.org/job/node-test-commit/14471/

addaleax · 2017-12-01T20:04:46Z

Landed in 31e0dbc

uses @@toStringTag when creating the "tag" for an inspected value PR-URL: #16956 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>

nodejs-github-bot added the util Issues and PRs related to the built-in util module. label Nov 11, 2017

devsnek changed the title ~~util: use @@toStringTag~~ util: use @@toStringTag in util.inspect Nov 11, 2017

refack approved these changes Nov 11, 2017

View reviewed changes

refack suggested changes Nov 11, 2017

View reviewed changes

TimothyGu suggested changes Nov 11, 2017

View reviewed changes

mscdex suggested changes Nov 11, 2017

View reviewed changes

addaleax mentioned this pull request Nov 12, 2017

WebAssembly support not easy to find #16952

Closed

addaleax reviewed Nov 12, 2017

View reviewed changes

addaleax approved these changes Nov 12, 2017

View reviewed changes

jasnell reviewed Nov 12, 2017

View reviewed changes

mscdex reviewed Nov 12, 2017

View reviewed changes

addaleax added the semver-minor PRs that contain new features and should be released in the next minor version. label Nov 12, 2017

mscdex reviewed Nov 13, 2017

View reviewed changes

jasnell approved these changes Nov 13, 2017

View reviewed changes

devsnek mentioned this pull request Nov 28, 2017

doc: clarify util.inspect usage intent #17375

Closed

2 tasks

devsnek force-pushed the feature/util-inspect-tostringtag branch from b48d0df to a107aaf Compare November 28, 2017 17:32

util: use @@toStringTag

46eef42

uses @@toStringTag when creating the "tag" for an inspected value

devsnek force-pushed the feature/util-inspect-tostringtag branch from a107aaf to 46eef42 Compare November 28, 2017 18:27

addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 30, 2017

addaleax closed this Dec 1, 2017

addaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Dec 1, 2017

devsnek deleted the feature/util-inspect-tostringtag branch December 1, 2017 21:04

BridgeAR mentioned this pull request Dec 28, 2017

Feature request: utilize Symbol.toStringTag in util.inspect #12780

Closed

kissofire mentioned this pull request Mar 7, 2021

[Snyk] Fix for 1 vulnerabilities kissofire/node#28

Open

meghasfdc mentioned this pull request Mar 8, 2021

[Snyk] Fix for 1 vulnerabilities meghasfdc/node#28

Open


		class Bar {}

		const Baz = Object.create(null, { [Symbol.toStringTag]: { value: 'foo' } });


		const Baz = Object.create(null, { [Symbol.toStringTag]: { value: 'foo' } });

		util.inspect(new Foo); // 'Foo [bar] {}'

util: use @@toStringTag in util.inspect #16956

util: use @@toStringTag in util.inspect #16956

Conversation

devsnek commented Nov 11, 2017 • edited Loading

Checklist

Affected core subsystem(s)

refack left a comment

Choose a reason for hiding this comment

refack commented Nov 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented Nov 11, 2017

mscdex left a comment • edited Loading

Choose a reason for hiding this comment

addaleax commented Nov 12, 2017

TimothyGu commented Nov 12, 2017

jasnell commented Nov 12, 2017

devsnek commented Nov 12, 2017 • edited Loading

addaleax commented Nov 12, 2017

jasnell commented Nov 12, 2017

devsnek commented Nov 12, 2017

devsnek commented Nov 12, 2017 • edited Loading

addaleax left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joyeecheung commented Nov 12, 2017

addaleax commented Nov 12, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Nov 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Nov 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mscdex commented Nov 12, 2017

Choose a reason for hiding this comment

mscdex Nov 13, 2017 • edited Loading

Choose a reason for hiding this comment

refack commented Nov 15, 2017 • edited Loading

refack commented Nov 15, 2017

devsnek commented Nov 15, 2017

addaleax commented Nov 15, 2017

TimothyGu commented Nov 15, 2017

addaleax commented Nov 15, 2017

devsnek commented Nov 15, 2017

refack commented Nov 15, 2017

evanlucas commented Nov 16, 2017

addaleax commented Nov 28, 2017

devsnek commented Nov 28, 2017

TimothyGu commented Nov 28, 2017

addaleax commented Nov 30, 2017

addaleax commented Dec 1, 2017

devsnek commented Nov 11, 2017 •

edited

Loading

mscdex left a comment •

edited

Loading

devsnek commented Nov 12, 2017 •

edited

Loading

devsnek commented Nov 12, 2017 •

edited

Loading

devsnek Nov 12, 2017 •

edited

Loading

devsnek Nov 12, 2017 •

edited

Loading

mscdex Nov 13, 2017 •

edited

Loading

refack commented Nov 15, 2017 •

edited

Loading