test.ts
class Foo
{
private foo= 8;
}
console.log( new Foo, );
// expect: Foo { foo: 8 }
// actually: Foo { foo: 8 }
test.js
class Foo
{
#foo= 8;
}
console.log( new Foo, );
// expect: Foo { #foo: 8 }
// actually: Foo {}
The output with the TypeScript private is irrelevant because it isn't a runtime thing, private is a TypeScript only construct at that point.
There appears to be inconstancy between Chrome and Node.js on this.
Chrome 74:
class Foo
{
#foo= 8;
}
console.log( new Foo, );
VM39:6 Foo聽{#foo: 8}
undefined
Node.js 12.4:
> class Foo
... {
... #foo= 8;
... }
undefined
>
> console.log( new Foo, );
Foo {}
undefined
I would have expected private members to not be logged actually, since they would be like non-enumerable properties too. But clearly there is inconsistency.
I think private members should be invisible for runtime but visible for debug. console.log is designed for debugging. Actually it is in In browser. But in Nodejs, it seams be used for write something on stdout.
We should clear what console.log be, a debugger or a stdout printer?
In my option, it should be debuger.
Deno.stdout.write for stdout but not have debugger for debug. console.log is designed for that at the first.How does rust handle this?
println!("object {:?}", some_object);
What about in Go
fmt.Printf("%+v\n", someObject)
Do they display private members?
Rust debug display log them but with no indication of their visibility:
#[derive(Debug)]
pub struct Foo {
foo: i64,
pub bar: i64,
}
pub fn main() {
let foo = Foo { foo: 8, bar: 8 };
println!("{:?}", foo);
}
Outputs:
Foo { foo: 8, bar: 8 }
This should be closed in favour of #3165.
Node's stringify has been tweaked and optimized over many years, but without private properties.
To a new spec like this, node is experienceless too.
Most helpful comment
Node's stringify has been tweaked and optimized over many years, but without private properties.
To a new spec like this, node is experienceless too.