util.inspect getters ignored on class instance #30183
Comments
|
class methods and accessors are nonenunerable. |
There are two reasons why it does not work for class instances: 1) getters are defined on the class's prototype, not on the instance itself and 2) they are not enumerable properties. You can solve it by defining the getter on the instance instead of the prototype: class Something{
constructor(){
Object.defineProperty(this, 'test', {
get(){ return 'test'; },
enumerable: true,
});
}
}
console.log(util.inspect(new Something, {getters: true})); |
|
Yes, I understand guys - thanks for explaining. I suppose I was expecting something like the Google Chrome behaviour. <!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>getters</title>
</head>
<body>
<script>
class Something {
get test () {
return 'test'
}
}
const something = new Something()
console.log(something)
</script>
</body>
</html>Google Chrome console output.
|
|
I take this as a feature request to print prototype properties as well. I thought about adding support for this before, it's just not trivial to know what properties are "useful" and which are not. We might want to print prototype properties in case the object is not a built-in. That way all user defined properties would be visible (just manipulated built-in prototypes would not be visible). |
BridgeAR
added
console
|
Hi, yes it's a feature request and relates specifically to the |
|
I am not sure what exactly you mean by that. Every object has a prototype (even if it's a I would implement it in a generic fashion to always print all prototype properties of the whole chain up to the first built-in. It should not print prototype properties of built-ins. That way all user properties from the prototype would be known. If someone would not use class Foo extends Map {
get abc() {
return 'abc'
}
}
Foo.prototype.property = true
class Bar extends Foo {
get xyz() {
return 'xyz'
}
}
const bar = new Bar()
console.log(bar)
// Bar [Map] {
// [xyz]: [Getter],
// [abc]: [Getter],
// [property]: true
// }
// No Map prototype properties are visible!
util.inspect.defaultOptions.getters = true
console.log(bar)
// Bar [Map] {
// [xyz]: [Getter: 'xyz'],
// [abc]: [Getter: 'abc'],
// [property]: true
// } |
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
Fixes: nodejs#30183
|
@BridgeAR Sorry for the slow response.
After reading this I realised that I misunderstood what the I had a quick play with your PR - generally, it's an improvement thanks. It sort-of solves my issue but I have some feedback... Take this trivial example. const util = require('util')
util.inspect.defaultOptions.getters = true
util.inspect.defaultOptions.showHidden = true
class Vehicle {
get state () {
return 'stationary'
}
start () {}
}
class Car extends Vehicle {
constructor () {
super()
this.fuel = 'deisel'
}
get windowCount () {
return 6
}
openWindow () {}
}
const car = new Car()
car.stop = function () {}
console.log(car)When run with node v13.2, neither the getters or their values are displayed. When run using your PR the getters and their resolved values are displayed. This only issue I personally have with the new output is that it displays everything, which can lead to some pretty heavy output. For example, here is the output when I With You can see the output quickly gets very busy. When i set |
|
@75lb I updated my PR to exclude functions for now, so it should pretty much do what you ask for. I think ideally, we'll have a fine grained option where it's possible to define what part users would use to see that are normally hidden. That way it would also be possible to define that you are only interested in prototype properties (excluding functions). The verbosity is in general a problem that can IMO only be solved in two ways: fine grained options for the user and later on a width first algorithm instead of a depth first one. The latter allows to count how many properties where already printed and limit the further inspection from that point on. It is not that trivial to implement that though. |
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
This makes sure that the regular expression matches all built-in objects properly. So far a couple where missed. PR-URL: #30768 Fixes: #30183 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
This makes sure that the regular expression matches all built-in objects properly. So far a couple where missed. PR-URL: nodejs#30768 Fixes: nodejs#30183 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: nodejs#30768
Fixes: nodejs#30183
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
This makes sure that the regular expression matches all built-in objects properly. So far a couple where missed. Backport-PR-URL: #31431 PR-URL: #30768 Fixes: #30183 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
Backport-PR-URL: #31431
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
This makes sure that the regular expression matches all built-in objects properly. So far a couple where missed. Backport-PR-URL: #31431 PR-URL: #30768 Fixes: #30183 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
Backport-PR-URL: #31431
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
getters:trueworks correctly on a plain object:Output:
But the same operation on a class instance fails to print the getter.
Output:
The output I expect to see is:
The text was updated successfully, but these errors were encountered: