| 14:40 | <haxjs> | The behavior of displaying class name of object in chrome console is weird : For `class Test {}` it will show `Test {}` even Test have `Symbol.toStringTag` defined. But for `class Test1 extends Test {}`, it will show `Foo {}` (assume `Test.prototype[Symbol.toStringTag]` is `"Foo"`). |
| 16:39 | <ljharb> | haxjs: in my chrome i see `class Test` and `class Test1` with `class Test { get [Symbol.toStringTag]() { return 'Foo'; } } class Test1 extends Test {} [Test, Test1]`, same for the instances |
| 16:40 | <ljharb> | haxjs: i'd only expect the toStringTag to show up with Object.prototype.toString, and indeed i see `new Test1() + ''` and `new Test() + ''` print `[object Foo]`. |
| 16:40 | <haxjs> | ljharb: this is another weird issue, getter have different behavior. |
| 16:41 | <haxjs> | On the other hand, Node.js have consistent and reasonable result. |
| 16:41 | <ljharb> | haxjs: `class Test {} Test.prototype[Symbol.toStringTag] = 'Foo'; class Test1 extends Test {} [Test, Test1]` gives me the same behavior in chrome's repl |
| 16:42 | <ljharb> | ah, i do see `new Test1()` in the second example print `Foo {}`, so that seems like a bug |
| 16:42 | <ljharb> | haxjs: specifically, if i then do `class Test {} Test.prototype[Symbol.toStringTag] = 'Foo'; class Test1 extends Test {} [Test, Test1]` it restores the proper behavior |
| 16:43 | <ljharb> | so the bug seems to be when Symbol.toStringTag is *enumerable* on a subclass, it incorrectly uses it |
| 16:43 | <ljharb> | (or, that it incorrectly ignores it when it's not enumerable, everywhere else, but that doesn't seem right to me) |
| 16:44 | <haxjs> | I guess it's a bug, but can't understand how this bug occur 😅 |
| 16:44 | <ljharb> | haxjs: want to file it? :-) |
| 22:01 | <Bakkot> | should `Reflect` have a toStringTag? |
| 22:01 | <Bakkot> | someone please have an opinion on this |
| 22:06 | <devsnek> | Bakkot: don't tempt me |
| 22:16 | <shu> | Bakkot: sure |
| 22:18 | <shu> | Bakkot: specifically, "sure" to the "let's retrofit all the namespace objects that don't have @@toStringTag with a @@toStringTag" |
| 22:19 | <shu> | though one day i would like to get out of the business of having opinions, that'd be nice |
| 22:37 | <ljharb> | Bakkot: yes, for debuggability |