-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Symbol key props visible in inspection by default #9726
Changes from 1 commit
903f353
192d79a
3ace6a9
8e73c95
3cbd847
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -371,10 +371,11 @@ function formatValue(ctx, value, recurseTimes) { | |
// Look up the keys of the object. | ||
var keys = Object.keys(value); | ||
var visibleKeys = arrayToHash(keys); | ||
var symbolKeys = Object.getOwnPropertySymbols(value); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I haven’t run this but right now this looks like this will include even *non-*enumerable Symbol properties? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup. That is how
I wouldn't mind changing it to exclude non-enumerable symbol-keyed props. Should I? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well… it seems a bit weird to list only enumerable string properties but all Symbol properties by default? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just don't know the reasons for not listing non-enumerable properties. For the sake of explaining my experience with the matter, I'll testify that I:
So, it may help that one with experience with the topic of enumerability and non-enumerability will share his thoughts. Also, the thoughts of one who knows the intention of symbols in this regard and why this is the behavior of |
||
keys = keys.concat(symbolKeys); | ||
|
||
if (ctx.showHidden) { | ||
keys = Object.getOwnPropertyNames(value); | ||
keys = keys.concat(Object.getOwnPropertySymbols(value)); | ||
keys = Object.getOwnPropertyNames(value).concat(symbolKeys); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the same result. The change is to not get the symbols twice. |
||
} | ||
|
||
// This could be a boxed primitive (new String(), etc.), check valueOf() | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -588,8 +588,9 @@ assert.doesNotThrow(function() { | |
'{ a: 123, inspect: [Function: inspect] }'); | ||
|
||
const subject = { a: 123, [util.inspect.custom]() { return this; } }; | ||
const UTC = 'util.inspect.custom'; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This trick is solely for line length. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems fine because this is in a small block. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMHO 'UTC' isn't a particularly good name. To me, it makes me think of Coordinated Universal Time, but the variable value does not hold anything date/time-related. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops. Just a typo. I meant UIC for
What is a good name? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mightyiam It might be best not to give this a name at all but instead spread the string below across multiple lines? |
||
assert.strictEqual(util.inspect(subject), | ||
'{ a: 123 }'); | ||
`{ a: 123,\n [Symbol(${UTC})]: [Function: [${UTC}]] }`); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a fix for a seemingly unrelated test that is affected. |
||
} | ||
|
||
// util.inspect with "colors" option should produce as many lines as without it | ||
|
@@ -659,7 +660,7 @@ if (typeof Symbol !== 'undefined') { | |
|
||
subject[Symbol('symbol')] = 42; | ||
|
||
assert.strictEqual(util.inspect(subject), '{}'); | ||
assert.strictEqual(util.inspect(subject), '{ [Symbol(symbol)]: 42 }'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This demonstrates the change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just the way I like it 😉 |
||
assert.strictEqual( | ||
util.inspect(subject, options), | ||
'{ [Symbol(symbol)]: 42 }' | ||
|
@@ -668,9 +669,8 @@ if (typeof Symbol !== 'undefined') { | |
subject = [1, 2, 3]; | ||
subject[Symbol('symbol')] = 42; | ||
|
||
assert.strictEqual(util.inspect(subject), '[ 1, 2, 3 ]'); | ||
assert.strictEqual(util.inspect(subject, options), | ||
'[ 1, 2, 3, [length]: 3, [Symbol(symbol)]: 42 ]'); | ||
assert.strictEqual(util.inspect(subject), | ||
'[ 1, 2, 3, [Symbol(symbol)]: 42 ]'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This assertion is removed because we already have an assertion above that symbol key properties are visible with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So in essence, this assertion is not instead of the one in 672, but instead of the one in 671. I guess it shows that symbol key properties can coexist peacefully with other properties in inspection. Or something about the order of properties? In any case, I'm guessing that the essence is preserved. |
||
} | ||
|
||
// test Set | ||
|
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.
I don't fully understand what goes on with
keys
vs.visibleKeys
, yet, this seems to work.