2023-07-26 [12:10:57.0875] it is *very* confusing that in the chrome console, `class T{ #b = 1; }; const t = new T(); console.log(t.#b);` works instead of throws. is that a bug worth filing? [12:12:07.0179] * it is _very_ confusing that in the chrome console, `class T{ #b = 1; }; const t = new T(); console.log(t.#b);` works instead of throws (it throws in safari, altho it doesn't parse so i have to do it in two lines). is that a bug worth filing? [13:11:52.0535] that is intentional afaik [13:11:56.0448] why is it very confusing? [13:12:29.0684] this was done with the hypothesis that when in a REPL debugging, developers expect to be able to access their private state [13:12:48.0044] yeah it used to throw, and there was a particular effort to make it work. It's only in the console, so it doesn't violate privacy. [13:12:48.0052] otherwise you can't debug private state easily at all [13:14:19.0213] there are other non-conformant behavior in the console like allowing let/const redecls at the same scope [13:14:36.0767] for the same reasons, that is, of better DX during REPL debugging [13:14:52.0110] What would be really great is if we could revive the effort to standardize JS console behavior, which has long differed from scripts and modules. Bradley was previously working on this. [13:15:05.0648] that was shut down by Allen last time IIRC [13:15:12.0151] but Allen is no longer actively participating [13:15:49.0555] well, we can review the counterarguments he made previously and see what the committee thinks [13:16:00.0108] yeah [13:16:25.0345] ultimately I think Allen's model of embedders/extensions and such differs from the way we've been moving, and I think that sort of thing was the sticking point [13:17:28.0163] This is the previous repo: https://github.com/bmeck/js-repl-goal [13:37:47.0302] I want cake and to eat it too. Strict mode repl, don't let me assign to non-writable prop, but also yay for letting me access private fields when debugging! [13:39:18.0613] yeah that could be a feature request, a 100% compliant repl mode [13:39:26.0693] dunno if devtools would be interested [13:40:45.0410] IIRC last time we asked (years ago with a different team) Chrome DevTools people liked the goal if it could be done well. Ultimately it's hard to say yes or no until more work has been done on the proposal. [13:41:33.0953] but yes we definitely shouldn't move forward with anything like this without engaging various devtools people [13:55:00.0401] > <@shuyuguo:matrix.org> why is it very confusing? a user on irc spent 6 hours trying to figure out why their code worked in the console and not anywhere else [13:55:39.0692] perhaps emitting a warning the first time someone access private data they're not "supposed" to be able to get in the repl, would be helpful? [13:56:19.0738] (iow, developers seem to _not_ expect the repl *input* to behave differently from real code, only the output) [13:59:59.0724] having a warning for non-compliant behavior like this is a great thing to file an issue about [14:00:13.0018] the not-input-but-output point is kind of tricky [14:00:42.0177] i think there's a pretty legitimate mental model where if you take a multiline file, you can evaluate it line-by-line by copy/pasting into a repl [14:01:10.0151] there's a bunch of things that are different between consoles besides this. e.g., consoles beat modules by years in supporting top-level await. [14:01:37.0645] and obviously the const/let redefinition which I don't think anyone is asking anyone to get rid of [14:01:45.0093] OTOH there's also data that devs _don't_ want the line-by-line mental model for let/const [14:01:50.0616] because convenience trumps there [14:01:56.0084] exactly [14:02:04.0220] so this seems more like a documentation issue [14:02:32.0828] but it'd also be kinda nice if the difference in behavior could ultimately be traced to, "the console is simply defined differently" rather than "Chrome does some silly thing" [14:03:36.0680] also if devtools want to keep innovating, we can specifically endorse the "also random extensions are cool, this is just the base" theory *just for consoles* [14:03:54.0735] while simultaneously defining cases that everyone wants to support [14:04:17.0436] yes, agreed on all points there [14:04:41.0902] ultimately I don't know if the "someone was confused for 6 hours" problem is solvable in general... that's sort of a thing that happens sometimes [14:05:46.0936] my personal opinion is that the driving design principle for devtools is just anticipating what users think is surprising, which is inconsistent from feature to feature [14:06:30.0018] in an ideal world you'd do actual research here [14:07:16.0178] I'm personally cool with things being kinda inconsistent, but I also don't really see why "the way JS is evaluated in a console" should be in the category of "competitive advantages from one devtools implementation to another"--ideally we'd make things less surprising by aligning [on what our research shows is less surprising] [14:26:08.0563] TG6: devtools spec [15:49:29.0940] lazy PSA for node folks: https://bugs.chromium.org/p/v8/issues/detail?id=14214 [15:49:42.0632] if someone here can help spread the word with node users 2023-07-27 [07:49:48.0028] > <@softwarechris:matrix.org> TG6: devtools spec Another aspect of this is https://github.com/w3c/webdriver-bidi [07:50:10.0961] > <@shuyuguo:matrix.org> lazy PSA for node folks: https://bugs.chromium.org/p/v8/issues/detail?id=14214 omg end of an era [07:54:29.0807] shared w/ my IBM/RedHat colleagues that are on the node TSC [08:20:44.0182] harmony is dead, long live harmony [08:25:29.0518] I thought 'harmony' was an alias for ES5 (to get out of the ES4 quagmire), but then I saw it used well out of that meaning, so always meant to ask what people actually meant by it. [08:26:34.0563] i don't actually know what people actually mean either [08:27:40.0283] there's some famous "harmony" email from Brendan about moving past ES4 to a minimal ES5 and then an idea to do stuff incrementally to form ES6, right? [08:28:27.0350] I'm pretty sure it didn't mention version numbers. [08:28:40.0774] * I'm pretty sure it didn't mention version/edition numbers. [08:29:09.0260] sure, so one may argue that we're still in the harmony era [08:29:56.0671] yeah, I'm wondering if people use it in that sense. [08:30:14.0884] well, now we have the "module harmony" program... [08:30:54.0055] i think that's my fault for continuing that use of the word [08:31:07.0767] no one can argue against "harmony" [08:31:13.0156] but in any case it's too inside baseball to be used as a public-facing flag [08:53:28.0152] friendship ended with harmony now discord is my best friend [11:42:12.0679] call me cloud [11:49:10.0235] shu: query: "Thanks for the heads up. Is that already the case in v8? Just wondering if we need to add flags that we build with/allow on command line" [11:50:17.0159] these are not build flags, but command-line flags to the v8 runtime [11:50:33.0423] i don't understand the "allow on the command line" part, is there an allowlist in some environments? [11:56:54.0693] Brendan's "harmony" email: http://web.archive.org/web/20230602054346/https://mail.mozilla.org/pipermail/es-discuss/2008-August/003400.html [12:01:18.0777] https://esdiscuss.org/topic/ecmascript-harmony also here, easier to see the thread [14:41:49.0097] > <@shuyuguo:matrix.org> i don't understand the "allow on the command line" part, is there an allowlist in some environments? > node '--harmony' may work today but node '--js-shipped' would result in an error [14:43:00.0010] > <@shuyuguo:matrix.org> i don't understand the "allow on the command line" part, is there an allowlist in some environments? * > in node.js we allow some command line options that apply to v8 to be specified. > Versus saying they are not valid options/ > node '--harmony' may work today but node '--js-shipped' would result in an error [14:47:28.0747] https://github.com/nodejs/node/blob/48345d0f6212d0c21922b5119c43c035013b7c5e/src/node.cc#L772 [14:50:47.0200] https://github.com/nodejs/node/blob/48345d0f6212d0c21922b5119c43c035013b7c5e/deps/v8/src/d8/d8.cc#L4743 [14:51:49.0146] haven't scrutinized this but it appears they won't have to make any changes as they are just pulling the options in from v8 itself [14:52:27.0466] oh okay, if flags are filtered, then `--js-` prefixed flags should be allowed through [14:57:13.0310] alright, well I've raised the issue so they are aware. thanks for the heads up! [14:57:30.0879] thanks for passing along the message [16:12:04.0641] fwiw i always thought it was the idea that ES 5 and 6 together were going to bring all JS together as One JS, in Harmony, but more loosely it referred to all the potential ES6 proposals, pre-ES6? not really sure obv