-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
util: allow symbol-based custom inspection methods #8174
Conversation
maybeCustomInspect !== exports.inspect && | ||
// Also filter out any prototype objects using the circular check. | ||
!(value.constructor && value.constructor.prototype === value)) { | ||
let ret = maybeCustomInspect.call(value, recurseTimes, ctx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: looks like the indent is off here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasnell This line is indented two spaces more than the opening if (
is, I think that’s the general rule. I know the code looks a bit weird, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alas, this is probably a result of our style choice of aligning the separate lines of the conditional.
At the risk of going off on a low-value irrelevant tangent: I have come to greatly dislike all the alignment stuff and wouldn't mind (at a minimum) removing the custom rules in ESLint that enforces it.
The main problems with alignment (from my perspective) are:
- Does not allow for modification in situations like this where alignment (which can wind up at any column) diminishes ease of scanning and understanding due to clashing with fixed indentation. Fixed indentation is more important than alignment IMO and so we should just ditch alignment and use fixed indentation or (more likely, given the churn) no rules at all everywhere that we are using alignment.
- As others have pointed out: Alignment looks great when you first do it. Then one line of the fourteen that are aligned gets changed, and you have to change all the others, resulting in more churn.
By the way, I'm pretty sure I wrote the custom rules that enforce alignment (after I got a nit or three about my failure to align stuff, probably), so I'll add: SORRY!!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I see it now... visually it looks off at first glance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Trott For the most part I think the alignment rules are okay, I see no need to change that or apologize for them. ;)
What I like to do in cases like this is actually not changing the alignment, but pulling the opening {
into its own line… I assume people here (and the linter) aren’t fans of that either, so it’s probably okay to leave it as it is right now. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addaleax I like to put the first part of the conditional on its own line so that it gets fixed indentation, but I'm also not sure others are a fan of that:
if (
somethingReallyLong &&
somethingElseThatIsAlsoReallyLong &&
oneMoreReallyLongThing
) {
doSomething();
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Trott … yeah … makes me wonder if Python is the only lang that got it right ;)
I’m going to leave this as it is if everyone’s okay with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, totally OK with that. Sorry for the distracting rant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Another rant for another time: Don't limit the line length to 80 characters?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, no need to apologize. :)
(Another rant for another time: Don't limit the line length to 80 characters?)
#holy-war ? ;)
Generally LGTM, I'd add the example of using |
e85abcb
to
4eb7232
Compare
Updated with nits addressed… CI: https://ci.nodejs.org/job/node-test-pull-request/3745/ I don’t know about recommending to no longer use |
Ok, yep, you're right. No need to rush it |
I find it weird that the Symbol's name starts with an uppercase. I don't know about other uses or best practice but it's not the case for well-known symbols like |
I’m happy with an all-lowercase variant too, |
Lowercase works for me On Sunday, August 21, 2016, Anna Henningsen notifications@github.com
|
3ef0b4c
to
1124ead
Compare
Updated using |
LGTM |
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: nodejs#8071
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection.
1124ead
to
2dc6163
Compare
Rebased to resolve conflicts with #8189 … new CI: https://ci.nodejs.org/job/node-test-commit/4747/ |
LGTM |
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: #8071 PR-URL: #8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection. PR-URL: #8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: nodejs#8071 PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection. PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: nodejs#8071 PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> PR-URL: nodejs#8437 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection. PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> PR-URL: nodejs#8437 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: nodejs#8071 PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> Refs: nodejs#8437 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection. PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> Refs: nodejs#8437 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: #8071 PR-URL: #8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> Refs: #8437 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection. PR-URL: #8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> Refs: #8437 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) #8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) #8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) #8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) #8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) #8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) #8174 Refs: #8428 Refs: #8457 PR-URL: #8466
Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) nodejs#8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) nodejs#8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) nodejs#8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) nodejs#8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) nodejs#8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) nodejs#8174 Refs: nodejs#8428 Refs: nodejs#8457 PR-URL: nodejs#8466
Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) nodejs/node#8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) nodejs/node#8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) nodejs/node#8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) nodejs/node#8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) nodejs/node#8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) nodejs/node#8174 Signed-off-by: Ilkka Myller <ilkka.myller@nodefield.com>
Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) nodejs/node#8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) nodejs/node#8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) nodejs/node#8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) nodejs/node#8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) nodejs/node#8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) nodejs/node#8174 Signed-off-by: Ilkka Myller <ilkka.myller@nodefield.com>
@thealphanerd I’ll open a backport PR and we can talk about that then (but generally I’d be in favour) EDIT: #9688 |
Add a `util.inspect.custom` Symbol which can be used to customize `util.inspect()` output. Providing `obj[util.inspect.custom]` works like providing `obj.inspect`, except that the former allows avoiding name clashes with other `inspect()` methods. Fixes: nodejs#8071 PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
If a custom inspection function returned `this`, use that value for further formatting instead of going into infinite recursion. This is particularly useful when combined with `util.inspect.custom` because returning `this` from such a method makes it easy to have an `inspect()` function that is ignored by `util.inspect` without actually having to provide an alternative for custom inspection. PR-URL: nodejs#8174 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
util
Description of change
Add a
util.inspect.Custom
Symbol which can be used to customizeutil.inspect()
output. Providingobj[util.inspect.Custom]
works like providingobj.inspect
, except that the former allows avoiding name clashes with otherinspect()
methods.Fixes: #8071
I’d appreciate feedback both on the symbol’s name and the way I changed the docs on custom inspection functions.