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

Activity

1. mscdex

   added

   feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.

   utilIssues and PRs related to the built-in util module.Issues and PRs related to the built-in util module.

   on May 1, 2017
2. mscdex commented on May 1, 2017

   

   mscdex

   on May 1, 2017

   Contributor

   More actions

   Alternatively you can currently do:

   [util.inspect.custom](depth, opts) {
     return this.type;
   }
3. jasnell commented on May 1, 2017

   

   jasnell

   on May 1, 2017

   Member

   More actions

   Yes, the util.inspect.custom bit works, but given that Symbol.toStringTag is a language standard, it should definitely be supported. That said, given that util.inspect is primarily intended as a debug mechanism, relying solely on Symbol.toStringTag may be problematic. Perhaps a hybrid approach...

   class Foo {
     get [Symbol.toStringTag]() { return 'Bar'; }
   }
   
   var foo = new Foo();
   console.log(foo);
   // Prints: Foo [@@toStringTag: Bar] { }
4. TimothyGu commented on May 1, 2017

   

   TimothyGu

   on May 1, 2017

   Member

   More actions

   General +1 from me. I actually tinkered with this idea a few months ago in a branch that has been destroyed because of an HD failure, but I'm willing to write a new patch if needed.

   Here are some of my findings:

   What we currently do to find the class name is walking the prototype chain, and we use the name of the first constructor property we see that both a) is a function and b) has a non-empty name. That brings up a few questions for @@toStringTag support:

   1. Should we should look for @@toStringTag as an own property first before walking the proto chain?
   2. Should we prefer @@toStringTag of a parent prototype over a constructor property of a child prototype? If not, should we prefer @@toStringTag over constructor of the same prototype, or vice versa?

   To 1 I'd answer yes, since that's also the choice taken by Object.prototype.toString. To 2, I'd say no to the first, and yes to the second (so that @@toStringTag overrides constructor in the same prototype object, but not child prototypes). I'm not too big of a fan of @jasnell's Foo [@@toStringTag: Bar] { } proposal. That's just a tad too busy, and I'd argue those who know of and set @@toStringTag probably know what to expect through doing that.
5. domenic commented on May 11, 2017

   

   domenic

   on May 11, 2017

   Contributor

   More actions

   Weak -1. toStringTag is really meant just for Object.prototype.toString.call(), not for generic debugging output. The util hooks seem better for that.

   But of course it's OK for debugging utils to take into account a large variety of signals, including ones not originally intended for debugging, so it's not a real problem.
6. BridgeAR commented on Dec 28, 2017

   

   BridgeAR

   on Dec 28, 2017

   Member

   More actions

   This got implemented in #16956. Closing.
7. BridgeAR

   closed this as completedon Dec 28, 2017