| 00:04 | <leobalter> | ystartsev akirose robpalme bterlson +{other chairs?] we should nominate André Bargull for the Ecma Fellow Award. |
| 00:07 | <leobalter> | This is optimistic and not a joke. I could stress some reasons why, but I'm pretty solid about my statement. |
| 00:28 | <akirose> | wanna put those reasons in an email to us? |
| 00:44 | <leobalter> | I'll try to write down some stuff. It should be around anba's extensive contributions to ECMA-262, ECMA-402, Test262 all in a personal capacity, probably unfunded for most of the work, if not 100% of it. |
| 01:03 | <Bakkot> | anba has the distinction of being the second-largest contributor to ecma-262 by number of commits |
| 03:14 | <ljharb> | candidate for ES2021 is released: https://github.com/tc39/Reflector/issues/361 |
| 03:23 | <devsnek> | ljharb: should it be on the agenda |
| 03:23 | <ljharb> | it is, part of the 262 update |
| 03:23 | <devsnek> | ah ok |
| 03:24 | <devsnek> | is this the thing where we go through the member list |
| 03:24 | <ljharb> | yeah |
| 03:25 | <devsnek> | exciting |
| 03:35 | <leobalter> | Bakkot: anba is the top contributor of ECMA-402 by number of commits. 5th in Test262, but that's just a rough idea. The contributions are pretty good in quality too. |
| 08:56 | <ystartsev> | leobalter: happy to add it to my slides -- did you send me an email (might have missed it) |
| 09:25 | <ystartsev> | Bakkot: leobalter added it: https://docs.google.com/presentation/d/1uwBpXKUaZPor14taHnguP29ur6q1gmshho6IHcGbF8w/edit#slide=id.gc5fb7997ab_0_0 |
| 09:27 | <leobalter> | Thanks ystartsev! I’m sending an email in the morning. I had some extra work today until late night so I got late on this. |
| 09:27 | <ystartsev> | no prob |
| 09:27 | <ystartsev> | i can also give you edit access to the slides? might be faster |
| 14:48 | <robpalme> | hello all, for today's plenary we are going to use Jitsi video conferencing for the first time. as usual, the link is given to you via the sign-in form. |
| 14:48 | <robpalme> | More details are on the Reflector meeting link: https://github.com/tc39/Reflector/issues/348 |
| 14:49 | <robpalme> | I encourage joining early to try out Jitsi features. We will start the Jitsi one hour before the real meeting for anyone wanting to do tech checks. |
| 16:10 | <robpalme> | the draft schedule is now posted on the reflector |
| 16:11 | <ryzokuken> | ty |
| 17:14 | <robpalme> | the Jitsi meeting is now started for anyone wishing to do a tech check |
| 17:20 | <brad4d> | I cannot login to Jitsi - it's asking me for a key |
| 17:21 | <brad4d> | (maybe password? my display is in Spanish for some reason) |
| 17:21 | <robpalme> | try using the password provided in the sign-in form |
| 17:21 | <brad4d> | "Clave necessario" |
| 17:21 | <brad4d> | right- duh |
| 17:41 | <leobalter> | ystartsev: I did an edit at the slides (André's slide only). I'm not sure if we should include that giving a fellow award to André is valuable for us to make sure the volunteer work is never blocked by them not being part of a member org. 6+ years of contributions is pretty fair for this. |
| 17:48 | <rkirsling> | wait, this app yells at you if you're not using Chrome? |
| 17:48 | <rkirsling> | that's pretty unfortunate |
| 17:52 | <rkirsling> | gonna try to use safari anyway and see what happens |
| 17:57 | <rickbutton> | what is missing from firefox/safari that makes video apps prefer chrome? |
| 17:57 | <rickbutton> | I hate having a single chrome tab for google meet and others |
| 17:58 | <ljharb> | rkirsling: safari doesn't work on it at app |
| 17:58 | <ljharb> | *all |
| 17:58 | <ljharb> | rkirsling: the audio is trash |
| 17:58 | <ljharb> | rkirsling: mobile safari too |
| 18:01 | <rkirsling> | audio seems okay |
| 18:01 | <rkirsling> | rickbutton: google meet works okay in safari 👍 |
| 18:01 | <michaelficarra> | this software seems nice so far |
| 18:02 | <ljharb> | rkirsling: hm, i ended up having to use the native app for it to work at all |
| 18:02 | <ljharb> | (on ipad) |
| 18:02 | <michaelficarra> | there was an info window that said something about requiring insertable streams |
| 18:02 | <michaelficarra> | I don't even know what those are |
| 18:05 | <rkirsling> | are there meant to be slides? |
| 18:05 | <rbuckton> | Minor complaint about jitsi, its hard to tell which audio device is which in settings: https://usercontent.irccloud-cdn.com/file/etG782LQ/image.png |
| 18:05 | <ryzokuken> | rkirsling: yelling for not using Chromium is an Igalia instance-specific thing 😅 |
| 18:05 | <ljharb> | that is a lot of audio devices |
| 18:05 | <rbuckton> | There's an ellipsis, but no way to expand. |
| 18:05 | <rkirsling> | (no worries if not I'm just making sure I'm not missing functionality) |
| 18:05 | <ryzokuken> | because we used to have issues with old firefox versions |
| 18:06 | <rbuckton> | I blame voicemeeter for the length of the list, but jitsi for the width of the list :) |
| 18:06 | <rkirsling> | ryzokuken: ah okay 😅 |
| 18:06 | <ljharb> | kind of weird that it doesn't highlight/prioritize the view of whoever's speaking |
| 18:07 | <ljharb> | (on the tile view) |
| 18:07 | <rbuckton> | ljharb: turn off tile view? but I see what you mean |
| 18:08 | <wsdferdksl> | Is there a way to get it to not cover up parts of the view with controls? |
| 18:08 | <michaelficarra> | wsdferdksl: toggle to the grid view? |
| 18:09 | <leobalter> | jitsi is beach balling |
| 18:09 | <rbuckton> | If you're not in tile view, you can hide the participant list in the bottom right corner: https://usercontent.irccloud-cdn.com/file/Ta9MuFJA/image.png |
| 18:09 | <leobalter> | I'm losing most of the audio |
| 18:10 | <shu> | oh whoa sam is on the call |
| 18:10 | <robpalme> | which client are you using leo? the audio is fine for me |
| 18:10 | <ryzokuken> | same on the electron client |
| 18:10 | <ljharb> | even in non-tile view tho the "big" person isn't always the speaker, is there a way to do that? |
| 18:11 | <shu> | wait are we supposed to be seeing slides |
| 18:11 | <ryzokuken> | no |
| 18:11 | <shu> | ok |
| 18:11 | <ryzokuken> | oh |
| 18:11 | <Bakkot> | ystartsev: killed the bot on the assumption we aren't trying to transcribe this |
| 18:11 | <ryzokuken> | I see them now? |
| 18:11 | <robpalme> | i am presenting |
| 18:12 | <leobalter> | robpalme: Web version on Safari, it recommends to use Chrome or Chromium as the only fully supported alternative |
| 18:12 | <leobalter> | it's going ok on Chrome |
| 18:12 | <rkirsling> | ooh those TCQ reactions got deployed |
| 18:12 | <ryzokuken> | leobalter: Safari has a few issues unfortunately :/ |
| 18:13 | <rkirsling> | hmm yeah slides remained a black box |
| 18:13 | <leobalter> | I understand, but it should be better to make that information available with the video link, before I join |
| 18:15 | <rkirsling> | FF displays slides |
| 18:16 | <robpalme> | leo, I will update the link to say Safari has known issues |
| 18:16 | <leobalter> | Thanks! |
| 18:16 | <ryzokuken> | robpalme: could you also recommend the electron app? That should work for most people and all platforms |
| 18:17 | <ryzokuken> | https://github.com/jitsi/jitsi-meet-electron |
| 18:17 | <rbuckton> | another jtsi "issue"? It uses `Shift+S` for fullscreen, but I use `Win+Shift+S` to take screenshots on Windows (like the two I posed above), which causes it to swap between fullscreen and windowed :(. |
| 18:17 | <leobalter> | ryzokuken: where is the electron app? the Downloads page only points to App Store, google play, etc |
| 18:18 | <ryzokuken> | I never knew the Shift+S shortcut before today! :D |
| 18:18 | <ryzokuken> | leobalter: https://github.com/jitsi/jitsi-meet-electron |
| 18:19 | <ryzokuken> | https://github.com/jitsi/jitsi-meet-electron/releases/tag/v2.6.1 was released 4 days ago, should work just fine. |
| 18:21 | <rkirsling> | oh the tcq reactions disappeared just as I was gonna try using 'em |
| 18:25 | <msaboff> | Whenever I connect, it disconnects within a minute and tries connecting again. |
| 18:26 | <robpalme> | Michael, which client are you using? |
| 18:26 | <msaboff> | Safari |
| 18:26 | <robpalme> | Jitsi does not seem to work in Safari. |
| 18:27 | <robpalme> | On iOS the native app works well |
| 18:27 | <rkirsling> | seems like everybody who's tried it has had a *different* issue but yes, latest FF is more stable |
| 18:27 | <msaboff> | I shouldn't have to download something to attend the meeting. |
| 18:28 | <msaboff> | What is wrong with what we used (Teams) for the last several meetings? |
| 18:28 | <robpalme> | yes, it's unfortunate it doesn't work in Safari |
| 18:29 | <ljharb> | msaboff: soooooo many things |
| 18:29 | <robpalme> | we had reports from multiple people of issues with Teams. |
| 18:29 | <msaboff> | So we are having an open standards meeting with a platform that doesn't work with more than one browser? |
| 18:29 | <haxjs> | It seems it works fine in Edge :) |
| 18:30 | <robpalme> | It works in Firefox |
| 18:30 | <msaboff> | Why should I have to download another browser to attend? |
| 18:33 | <robpalme> | there are also desktop clients available https://desktop.jitsi.org/Main/Download |
| 18:35 | <rbuckton> | littledan: Different regexp engines handle duplicate capture groups in different ways. May need to investigate options... |
| 18:37 | <littledan> | rbuckton: Oh, that's interesting, do you know if there's a summary anywhere? |
| 18:37 | <littledan> | I guess jitsi sort of works with Safari, just not with very good performance on video, right? |
| 18:38 | <rbuckton> | littledan: I'm working on a comprehensive comparison of regexp engines, but haven't written anything up about that yet |
| 18:38 | <haxjs> | It seems jitsi should work on safari but just have some bugs... |
| 18:39 | <ryzokuken> | littledan: Jordan had many issues trying to make it work on Safari too :( |
| 18:39 | <littledan> | :( |
| 18:39 | <ljharb> | littledan: when i tried it yesterday, on desktop the audio was jittery and unhearable, and on mobile it was silent |
| 18:39 | <littledan> | oh, I thought that was due to video, I misunderstood |
| 18:39 | <ljharb> | the video quality was worse, yes, but otherwise usable |
| 18:39 | <rkirsling> | audio was fine for me but slides wouldn't appear |
| 18:39 | <littledan> | that's too bad |
| 18:40 | <littledan> | Safari users, is there a video conferencing system that you'd recommend better? |
| 18:40 | <littledan> | (WebEx?) |
| 18:40 | <littledan> | maybe we could work together on fixing Jitsi--it's an open-source project... |
| 18:41 | <ryzokuken> | yeah, they just have very little number of contributors running Safari |
| 18:42 | <ryzokuken> | ideally, even filing in issues would be enough I think :D |
| 18:42 | <littledan> | wow, we are doing awesome on time! |
| 18:43 | <rickbutton> | we should file a bug report for that slide problem |
| 18:43 | <littledan> | consensus on seeing slides |
| 18:44 | <rickbutton> | +1 for seeing slides for stage 1 |
| 18:44 | <ryzokuken> | :P thanks we'd ask for Stage 2 next meeting then |
| 18:50 | <wsdferdksl> | too many issues with jitsi |
| 18:53 | <rbuckton> | I have two monitors, and even with jitsi fullscreen on one monitor, I keep getting a PIP window of the same slides in my other monitor :/ |
| 18:53 | <ryzokuken> | wsdferdksl: the one specific issue with visual clutter that you mentioned is something that I've felt too, and it also frustrates us when we try to record presentations over Jitsi. |
| 18:54 | <ryzokuken> | so I'll try to come up with a custom CSS hack that can toggle the controls for now |
| 18:54 | <ryzokuken> | and ask for that feature on the issue tracker to be built into the client. |
| 18:55 | <ryzokuken> | for the time-being, I usually just right click to open the inspector and turn off the elements manually. |
| 19:02 | <michaelficarra> | I am open to forgetting about species |
| 19:06 | <michaelficarra> | FYI there is a per-person volume bar in the top right corner of the person's tile |
| 19:06 | <leobalter> | If I could only find the person's tile |
| 19:07 | <michaelficarra> | hover over the hamburger to make it appear |
| 19:07 | <michaelficarra> | leobalter: it's the one surrounded in blue |
| 19:07 | <Bakkot> | this presentation ought to have mentioned that `reverse` and `reversed` is already how python spells these methods |
| 19:07 | <rickbutton> | ^ great point |
| 19:07 | <leobalter> | michaelficarra: I'm pretty sure it was not showing in my screen |
| 19:07 | <michaelficarra> | leobalter: it's a little subtle |
| 19:08 | <rkirsling> | Bakkot: +1 |
| 19:09 | <leobalter> | michaelficarra, DR tile is not here and that didn't happen while he was speaking either. https://usercontent.irccloud-cdn.com/file/tppB37vN/Screen%20Shot%202021-03-09%20at%2011.08.13%20AM.png |
| 19:09 | <michaelficarra> | leobalter: that pane scrolls |
| 19:10 | <leobalter> | thanks! that should solve the problem next time! |
| 19:10 | <ljharb> | i'm told igalia disabled the feature where it pins whoever's talking |
| 19:10 | <michaelficarra> | blame your OS for hiding scroll bars |
| 19:10 | <michaelficarra> | that's a terrible UI decision |
| 19:10 | <ljharb> | yuppppp |
| 19:10 | <leobalter> | yes |
| 19:10 | <ljharb> | first things i do on any mac is to unhide scrollbars and disable "natural" scrolling |
| 19:11 | <michaelficarra> | another example of making it pretty at the expense of usability from Apple |
| 19:12 | <haxjs> | Not sure I asked the correct question... What I asked is it seems `let deleted = a.slice(...); let newArray = a.spliced(...)` repeat some computation. Maybe `let [newArray, deletedItems] = a.spliced(...)` ? |
| 19:14 | <TabAtkins> | haxjs: Your question was correct, it was just misinterpreted. ^_^ I've seen both patterns, I think, in other languages with non-mutating methods, and I'm not sure which I prefer. :/ |
| 19:16 | <rickbutton> | oh I see your question now haxjs, please open an issue for spliced |
| 19:16 | <rickbutton> | worth discussion |
| 19:16 | <ljharb> | tbh i don't even know if "splice" has enough use cases to warrant "spliced" :-p |
| 19:16 | <ljharb> | almost every time i've come across splice in the last decade or two is because someone misspelled slice |
| 19:17 | <haxjs> | Will we have a separate repo for these new methods? so I can create issue for that? |
| 19:17 | <rickbutton> | I would create the issue on the Record/Tuple repo. Whatever it returns, it should return the same for both. |
| 19:17 | <ljharb> | jridgewell: IIFE boilerplate is a high cost. |
| 19:17 | <rickbutton> | ljharb: not wrong but consistency |
| 19:18 | <ljharb> | rickbutton: right |
| 19:18 | <haxjs> | @rickbutton thank u! |
| 19:18 | <rickbutton> | I have to look up splice on MDN every time I use it |
| 19:19 | <ljharb> | rickbutton: i _implemented_ it in es6-shim and i still can't figure out its api without a few tries |
| 19:19 | <rickbutton> | :) |
| 19:22 | <jridgewell> | Compared with the syntax, it's dozen restrictions, and having to learn completion values? |
| 19:22 | <jridgewell> | I don't think there's any point to this proposal if it's just sugar. |
| 19:22 | <Bakkot> | fwiw I care more about async do, and that one _is_ just sugar under any variant of this |
| 19:23 | <ljharb> | i don't think anyone has to learn most of the completion values; i think it's quite intuitive (and the weird cases should be banned or fixed) |
| 19:23 | <ljharb> | jridgewell: i hear that you don't find value in it. many of us do, tho. |
| 19:24 | <ljharb> | literally even being able to use `const` with an if/else-produced value would be more than sufficient benefit to me |
| 19:24 | <ljharb> | (obv there's many more benefits than that) |
| 19:26 | littledan | applauds |
| 19:28 | <littledan> | yeah, so I was specifically saying, I don't think it's important that study participants be able to answer the kind of question that Waldemar asks |
| 19:35 | <Bakkot> | jridgewell do you have similar feelings about async do? |
| 19:36 | <ljharb> | TabAtkins: did you get an answer to your multipage question in jitsi chat? i think it's "yes" |
| 19:36 | <TabAtkins> | I didn't, but thanks! |
| 19:36 | <leobalter> | https://usercontent.irccloud-cdn.com/file/yUvdt4SA/Screen%20Shot%202021-03-09%20at%2011.36.29%20AM.png |
| 19:37 | <jridgewell> | Bakkot: Yes, it's the same |
| 19:37 | <Bakkot> | jridgewell so async do fundamentally can't allow return or continue |
| 19:37 | <Bakkot> | since it's not executing at the same time |
| 19:37 | <littledan> | btw were there any technical problems before this one? |
| 19:37 | <Bakkot> | does that mean you're opposed to async do in general? |
| 19:37 | <rickbutton> | ron had to restart once littledan |
| 19:37 | <haxjs> | @jridgewell I feel if it's not just sugar it also could bring more problems than benefit ... :) |
| 19:37 | <msaboff> | littledan: Only accessing the meeting! |
| 19:38 | <littledan> | (we definitely had problems with Teams not supporting non-Chrome browsers in the past) |
| 19:38 | <rickbutton> | we should just switch back to zoom, the only consistently consistent experience |
| 19:38 | <littledan> | and also problems with screensharing being broken in Teams |
| 19:38 | <akirose> | "back to" have we ever used Zoom? |
| 19:39 | <akirose> | several companies don't allow Zoom on corporate laptops |
| 19:39 | <rickbutton> | we used zoom like once in the start of the pandemic |
| 19:39 | <ljharb> | +1 for zoom |
| 19:39 | <ljharb> | zoom has a webview |
| 19:39 | <rickbutton> | yep they try real hard to hide it |
| 19:39 | <ljharb> | my company wouldn't allow me to install any of the native chat apps, jitsi include it |
| 19:39 | <ljharb> | *included |
| 19:39 | <rbuckton> | I've been reporting feedback to the Teams dev team. |
| 19:39 | <Bakkot> | jridgewell btw the motivation for async do is basically this tweet: https://twitter.com/mcclure111/status/1336911574582386688 |
| 19:39 | <Bakkot> | (which expresses a sentiment I feel myself on an almost daily basis) |
| 19:39 | <rkirsling> | nice |
| 19:40 | <ljharb> | ^ IIFE boilerplate is an exceedingly high cost. |
| 19:40 | <haxjs> | So maybe IIFE sugar is just what people want... |
| 19:41 | <Bakkot> | other people also want the nice early-return-in-matching thing that do-exprs allow |
| 19:41 | <littledan> | Does Zoom work on Safari? It's not clear what problem this is solving. |
| 19:41 | <haxjs> | Note here if the main use case is replacing IIFE, we need to support local return, because many IIFE use early return (guard pattern). |
| 19:42 | <ljharb> | littledan: yes, zoom works fine on safari |
| 19:42 | <ljharb> | littledan: altho to be fair i don't spend much time in the web version |
| 19:59 | <rkirsling> | is it by his own choice that he never comes to plenary? |
| 20:00 | <ryzokuken> | rkirsling: they do not work for a member IIUC |
| 20:00 | <shu> | sorry what is the difference between Fellow and Recognition Award |
| 20:00 | <rkirsling> | oh I thought he was a mozillian |
| 20:00 | <ryzokuken> | shu: fellow is a lifetime achievement award |
| 20:00 | <ryzokuken> | and the latter is more commonly given out |
| 20:00 | <shu> | does one of them come with CHFs |
| 20:01 | <ryzokuken> | idk but probably just glass bricks |
| 20:01 | <ljharb> | shu: iirc a fellow can attend forever without being a member |
| 20:01 | <ryzokuken> | leobalter: thank you so much for nominating anba :D |
| 20:01 | <ljharb> | shu: ie, brendan and allen |
| 20:01 | <shu> | ljharb: oh interesting |
| 20:02 | <ljharb> | (i think they don't get a vote on votable things tho) |
| 20:02 | <leobalter> | they don't get a vote |
| 20:03 | <leobalter> | ryzokuken: I believe we can set a good example while we maintain ourselves as welcoming to André's contributions |
| 20:03 | <ryzokuken> | when did we last vote on something? |
| 20:03 | <ryzokuken> | leobalter: yes! I saw you suggesting them and was like "why did I never do this?" |
| 20:03 | <ryzokuken> | but yeah, their work is amazing |
| 20:04 | <rkirsling> | so did the tcq reactions get hidden then? |
| 20:04 | <shu> | i think it's a good point, though, that if one of the primary benefits of an Ecma fellow is to be able to come to the meetings, and he doesn't come |
| 20:04 | <shu> | i'd rather shower him with money |
| 20:04 | <rkirsling> | I saw them there for the first couple of presentations and then they disappeared |
| 20:06 | <ljharb> | msg littledan only andre is suggested as a fellow, i think |
| 20:06 | <ljharb> | lol forgot a / |
| 20:08 | <littledan> | oh, oops, I guess I would've known that if I clicked on the slides, I was just confused, sorry |
| 20:09 | <littledan> | Andre has certainly made outstanding contributions and I'd be happy to give him lots of honors |
| 20:09 | <rbuckton> | quick point: If we're serious about `yea`/`nay`, we should ask them as independent questions rather than a single question because its hard to differentiate between them when everyone talks at once. |
| 20:09 | <littledan> | tbh we set up the "Ecma Fellows" program at first because there was no invited expert system, and people at first wanted to have really high standards for this kind of thing |
| 20:22 | <ystartsev> | the yea/nay was a spur of the moment thing, we don't have to repeat it |
| 20:22 | <ystartsev> | i wanted to make sure people could say no |
| 20:22 | <ystartsev> | i hope it worked |
| 20:28 | <ystartsev> | (also was in the interest of time, really) |
| 20:36 | <ljharb> | littledan: you're not presenting, right, just practicing? |
| 20:36 | <littledan> | Right, sorry if it is distracting |
| 20:37 | <rkirsling> | I got worried too lol |
| 20:38 | <ljharb> | just panicked that i'm missing things |
| 20:39 | <rickbutton> | nope we are starting back up in 21 mins |
| 21:00 | <jridgewell> | To preemptively explain a question that will come up with this: "What's the difference between module fragments and module blocks" |
| 21:00 | <jridgewell> | The way I found useful to think about is that Fragments are like Function Declarations (must have identifier) and Blocks are like Function Expressions. |
| 21:00 | <jridgewell> | The Fragments have additional abilities the Blocks don't. |
| 21:02 | <ljharb> | hm, i don't hear anything |
| 21:02 | <ljharb> | rejoining |
| 21:03 | <jridgewell> | (and there's an error on that slide, it should say "can't close over countBlock or uppercaseBlock") |
| 21:03 | <ljharb> | k, rejoining fixed it |
| 21:04 | <shu> | really, a JS app has 100k modules? |
| 21:04 | <michaelficarra> | jridgewell: thanks, that makes more sense |
| 21:05 | <rickbutton> | shu: gmail? |
| 21:05 | <rickbutton> | or docs |
| 21:05 | <shu> | those aren't written in JS natiely |
| 21:05 | <shu> | natively* |
| 21:05 | <ljharb> | shu: airbnb had 30,000 react components when i left in july 2019, and many more modules than that |
| 21:06 | <rickbutton> | jesus |
| 21:06 | <shu> | ljharb: i see, thanks |
| 21:06 | <rickbutton> | facebook certainly has more still if thinking about React components |
| 21:06 | <rickbutton> | since most codebases do 1 component per moudle |
| 21:07 | <ljharb> | the last time i'd checked with both, airbnb had more components than facebook (altho possibly not more modules) |
| 21:07 | <ljharb> | (that was a number of years ago tho) |
| 21:14 | <drousso> | i wonder if maybe we could use `private module` and `public module` here 🤔 |
| 21:15 | <ljharb> | drousso: to be that's the same problem with using those terms on class fields; JS only has "reachable" and "unreachable" |
| 21:15 | <haxjs> | it seems `export module` could ensure it always in top-level. And all module not exported is just "private"? |
| 21:15 | <ljharb> | like any other variable, yes |
| 21:15 | <ljharb> | (i'd assume) |
| 21:16 | <drousso> | i suppose |
| 21:16 | <shu> | drousso: you mean `#module` and `module`? |
| 21:16 | <drousso> | shu not really? 😅 |
| 21:16 | <drousso> | shu it was an alternative to `export module` |
| 21:16 | <jridgewell> | I like the export/un-exported distinction |
| 21:16 | <drousso> | i guess also since we're already inside a module context then `export` is more understandable |
| 21:16 | <drousso> | yeah |
| 21:17 | <shu> | drousso: ah okay |
| 21:17 | <haxjs> | what happened on `export default module #foo` ? syntax error? |
| 21:19 | <jridgewell> | haxjs: Yes |
| 21:20 | <jridgewell> | The exports aren't a value, so that wouldn't result in anything that could be imported |
| 21:21 | <ljharb> | like anything that can't appear in expression position, i'd assume so |
| 21:21 | <haxjs> | so does it mean `module #foo {}` actually a special thing and can only in top-level? |
| 21:22 | <jridgewell> | Yes |
| 21:22 | <jridgewell> | It's a module-level declaration only |
| 21:23 | <ljharb> | like import and export |
| 21:23 | <robpalme> | dan is saying that splitting into separate modules has demonstrable perf issues |
| 21:24 | <robpalme> | that can be mitigated by combining them into fragments |
| 21:27 | <michaelficarra> | is the idea that you can declare any module specifier or only a fragment at the containing module's URL? |
| 21:28 | <robpalme> | only a fragment |
| 21:28 | <haxjs> | should only fragment |
| 21:28 | <michaelficarra> | interesting, how does that work with other ecosystems that use non-URL module specifiers? |
| 21:29 | <haxjs> | like node? |
| 21:29 | <robpalme> | so you are declaring a subdivision (a fragment) that can be externally referenced |
| 21:29 | <michaelficarra> | yeah a fragment isn't really a thing in the node module specifier namespace |
| 21:29 | <ljharb> | yes it is |
| 21:29 | <michaelficarra> | oh, it is? |
| 21:29 | <ljharb> | package.json files can have an "imports" field |
| 21:29 | <ljharb> | and those are like a package-local import map |
| 21:29 | <ljharb> | and those all have to start with `#` |
| 21:30 | <jridgewell> | AMP is affirmatively for this. |
| 21:30 | <ljharb> | michaelficarra: https://www.npmjs.com/package/has-package-imports is my detection package, which lists node versions and links to the docs |
| 21:30 | <haxjs> | a interesting thing is import x from './mod/lib.js#foo' maybe already work today ... not sure whether it will be any compat issue... |
| 21:31 | <keith_miller> | littledan: I'm happy to be a lowercase c co-champion haha |
| 21:31 | <keith_miller> | I have a lot of things on my plate though... |
| 21:31 | <keith_miller> | So, I may or may not have a ton of time. |
| 21:31 | <littledan> | yeah I think we can all bring different things to the table here so I'm happy to work with keith_miller and Mark as they're available |
| 21:31 | <littledan> | and any others--there's no limit here |
| 21:32 | <michaelficarra> | ljharb: this imports thing seems unrelated to what is proposed |
| 21:32 | <ljharb> | michaelficarra: right but in node you can currently `import 'package-name/#foo'` and it does a thing |
| 21:32 | <TabAtkins> | Re: normalization, yes yes *yes*, it's, I think, the largest reason we can't use native Maps in the DOM. |
| 21:32 | <ljharb> | michaelficarra: so if package-name's "main" had an exported module fragment, there's a conflict |
| 21:32 | <michaelficarra> | okay so you're saying it's actually related in its incompatibility with that system |
| 21:33 | <ljharb> | correct |
| 21:33 | <michaelficarra> | I thought you were saying it worked well with that system |
| 21:33 | <haxjs> | @littledan Jack may be also interested in module fragment but he is sleeping now, i will ask him tommorow :) |
| 21:33 | <ljharb> | michaelficarra: ah no, the reverse |
| 21:33 | <ljharb> | can the queue be advanced? |
| 21:33 | <ljharb> | akirose robpalme bterlson ^ |
| 21:34 | <ljharb> | ty |
| 21:34 | <akirose> | my b |
| 21:34 | <jridgewell> | ljharb: This seems like a really small edge-case |
| 21:34 | <jridgewell> | Same as in the browser. It technically already does something, but what it does is dumb, and I've never seen it used. |
| 21:34 | <ljharb> | jridgewell: i'm not sure how small it is, but i'm also not sure how its size makes a difference - it'd still have to be dealt with |
| 21:35 | <ljharb> | you've not seen it used because it's very new, and most tooling doesn't support it yet |
| 21:35 | <ljharb> | as for "is dumb", that's a subjective opinion i'm not sure how many will share |
| 21:35 | <ljharb> | wsdferdksl: can you confirm the last time we talked about this, that you'd be content with "Set can accept coerceKey or coerceValue, but not both"? |
| 21:36 | <haxjs> | jridgewell : "and I've never seen it used" --- not sure but someone may use it by import.meta.url ? (does import.meta.url keep fragment??) |
| 21:36 | <ljharb> | given that import maps can act on it, i'd hope so |
| 21:37 | <littledan> | haxjs: That's great to hear, I'm a big fan of Jack's work and I'd be happy to work with him on this effort |
| 21:40 | <jridgewell> | `import.meta.url` does include hash: https://candy-nutritious-cantaloupe.glitch.me/ |
| 21:41 | <haxjs> | I used searchparam via import.meta.url in some code but never test fragment, glad it also work :P |
| 21:46 | <TabAtkins> | keys and set values are both the things with uniqueness constraints. set values are not map values :/ |
| 21:46 | <jridgewell> | Param makes sense though, since it actually causes a fetch |
| 21:47 | <jridgewell> | Hash can't cause a fetch, but does create a new module instance, which is extremely surprising |
| 21:50 | <jridgewell> | Some's child is speaking? Is someone other than Jordan umuted? |
| 21:51 | <ljharb> | shu: what would it do for a Set if it returned `[1, 2]` - which one would it select |
| 21:51 | <ljharb> | or are you saying that the coercer could check `arguments.length` |
| 21:53 | <wsdferdksl> | ljharb: that would be ok |
| 21:53 | <haxjs> | What first mean here? |
| 21:53 | <ljharb> | wsdferdksl: thanks |
| 21:53 | <ljharb> | haxjs: `[0]` on the entry |
| 21:53 | <haxjs> | but it's an option bag? |
| 21:54 | <ljharb> | but i assume shu is suggesting `function coerce(...args) { if (args.length === 1) { /* set */ } else if (args.length === 2) { /* map */ } }` |
| 21:54 | <haxjs> | oh?? |
| 21:54 | <ljharb> | keith_miller: the same function could still return different results for both calls |
| 21:54 | <ljharb> | keith_miller: which would be nonsensical on a Set |
| 21:55 | <keith_miller> | ljharb: I just mean for Set if they are the same you would call the function once |
| 21:55 | <ljharb> | keith_miller: right, but then the coercer fn would have to know that's the case, where it might be expecting one call for key and one for value |
| 21:55 | <keith_miller> | well, I mean that's a bug I guess |
| 21:56 | <rickbutton> | could pass a "type" |
| 21:56 | <rickbutton> | although you have to name the type :/ |
| 21:56 | <ljharb> | yup |
| 21:56 | <keith_miller> | I dunno, that seems like an unusual use case |
| 21:56 | <rbuckton> | I thought shu was suggesting something like: |
| 21:56 | <rbuckton> | ``` |
| 21:56 | <rbuckton> | function coerce(entry, kind) { |
| 21:56 | <rbuckton> | if (kind==="key+value") { /* map, entry is [key, value] */ } |
| 21:56 | <rbuckton> | else { /* set */ |
| 21:56 | <rbuckton> | } |
| 21:56 | <rbuckton> | ``` |
| 21:56 | <rbuckton> | Seeing as how we use `key+value` for map iterators |
| 21:56 | <ljharb> | ah true, that would work too |
| 21:56 | <keith_miller> | ljharb: I would generally expect the coercer function to be pure |
| 21:56 | <ljharb> | keith_miller: as would i, but, javascript |
| 21:57 | <keith_miller> | haha yeah fair |
| 21:57 | <shu> | ljharb: if maps and sets are the only collections in your universe of collections, sure |
| 21:57 | <keith_miller> | Not sure we should design around all possible things JS programmers could do though |
| 21:57 | <shu> | the important thing was just: use positional parameters that match the positions to the set/add/whatever function that actually adds new entries to the collection |
| 21:57 | <shu> | and ignore names |
| 21:57 | <ljharb> | right |
| 21:58 | <shu> | so a 1-ary coercer could be used for Arrays and Sets |
| 21:58 | <shu> | but that kind of reuse is probably nonsensical |
| 21:59 | <keith_miller> | Yeah, IMO the return being an Array makes me :( |
| 21:59 | <shu> | to avoid the Array allocation issue, you can provide an array of coercers |
| 21:59 | <shu> | [coercer_for_param1, coercer_for_param2] |
| 21:59 | <keith_miller> | O.o |
| 21:59 | <shu> | that's no different than { coerceValue, coerceKey }, right? just not named |
| 22:00 | <keith_miller> | That's fair although I think it will have the same issue that the Map iterator has |
| 22:00 | <shu> | what's that? |
| 22:00 | <rickbutton> | does that mean you need to pass [coercer] for a Set? |
| 22:00 | <shu> | rickbutton: yes, i'd say so |
| 22:00 | <shu> | but that's only at Set creation time, which should be much rarer than actually using the Set |
| 22:00 | <rickbutton> | ew for the same reason as returning [newValue] from a Set coercer |
| 22:00 | <ljharb> | then you couldn't reuse the same options bad for a map and a set tho, which was the original complaint |
| 22:00 | <shu> | ljharb: why can't you? |
| 22:01 | <shu> | ljharb: you can pass an array with more coercers than will be used, the rest can be ignored |
| 22:01 | <ljharb> | ohh i see what you mean |
| 22:01 | <ljharb> | ok, sure |
| 22:01 | <shu> | it works for waldemar because it so happens that the "key" of the set is the only param, and the key for Maps is the 1st |
| 22:01 | <shu> | but there's no "deep" reason, it's just the order they appear |
| 22:02 | <keith_miller> | shu: If you do map.entries() you get [key, value], which is mostly annoying because destructuring uses array iterator |
| 22:02 | <drousso> | would be nice for `Map` tho if there's a way to coerce both the key and value at the same time (i.e. coerce the value based on the key) |
| 22:03 | <shu> | drousso: well, the current proposal falls short there too, right? |
| 22:03 | <drousso> | yeah |
| 22:03 | <shu> | keith_miller: yeah, but you do that iteration protocol presumably once, at creation time |
| 22:03 | <shu> | so maybe it's ok |
| 22:03 | <keith_miller> | Yeah, it's probably fine |
| 22:03 | <drousso> | im still not really convinced of the need/benefit of this over just modifying `map.set = function() { ... }` |
| 22:04 | <drousso> | but i don't have a strong opinion |
| 22:04 | <shu> | oh don't monkeypatch bro |
| 22:04 | <keith_miller> | drousso: use subclassing!! |
| 22:04 | <shu> | no |
| 22:04 | <drousso> | or subclassing |
| 22:04 | <shu> | no |
| 22:04 | <shu> | nooo |
| 22:04 | <michaelficarra> | we really need to have a conversation about how we expect subclassing to work in this language… |
| 22:04 | <shu> | i'll extend that sentiment, yes |
| 22:04 | <ljharb> | might be a relevant topic for this proposal |
| 22:05 | <michaelficarra> | and the previous topic |
| 22:05 | <keith_miller> | I expect it to work how I want to use it in the current circumstance :P |
| 22:05 | <ljharb> | shu: what a derived joke |
| 22:05 | <keith_miller> | Wait are we against subclassing now? |
| 22:05 | <drousso> | ^ +1 |
| 22:05 | <michaelficarra> | seriously though, I don't think we can make progress on some of these proposals without that conversation first |
| 22:06 | <rbuckton> | One thing I've considered proposing is providing a way to control equality in a Map/Set (essentially via `{ equal(a, b) { ... }, hash(a) { ... }`), which would only operate on the runtime value that determines existence in the collection. For a `Map` that's only ever the key, for a `Set` that's the key/value. As much as I'm in the camp of "A `Set` stores unique *values*", the similarity with how keys are |
| 22:06 | <rbuckton> | treated in `Map` and values are treated in `Set` is making me lean towards using `{ coerceKey }` for `Set` (where "key" means "the runtime value compared to other runtime values to indicate presence in the collection") |
| 22:06 | <keith_miller> | michaelficarra: but that didn't answer my question lol |
| 22:06 | <michaelficarra> | keith_miller: no, we just don't have a good way to do it |
| 22:06 | <keith_miller> | in what sense? |
| 22:07 | <michaelficarra> | see the Set methods proposal and our last discussion there |
| 22:07 | <keith_miller> | do you mean in the spec? |
| 22:07 | <keith_miller> | or for end users? |
| 22:07 | <michaelficarra> | do we make some core API that all operations observably go through? |
| 22:07 | <michaelficarra> | for end users |
| 22:07 | <shu> | keith_miller: i am against subclassing, yes |
| 22:08 | <michaelficarra> | how we design built-ins to support subclassing |
| 22:08 | <shu> | keith_miller: yulia and i have that proposal to kill subclassing |
| 22:08 | <michaelficarra> | shu: same, but that's different |
| 22:08 | <haxjs> | I guess most end users think Set only have value, no key... |
| 22:08 | <keith_miller> | I think of sets as only having keys lol |
| 22:09 | <keith_miller> | i.e. it's Map<Type, void> |
| 22:09 | <rkirsling> | ^ same but that's why we have both aliased |
| 22:09 | <shu> | i think of sets as having keys, yes |
| 22:09 | <ljharb> | keith_miller: `Set.prototype[Symbol.iterator].name` disagrees with you |
| 22:09 | <michaelficarra> | sets have "elements" which are analogous to map keys |
| 22:09 | <ljharb> | keith_miller: also `Set.prototype.keys.name` |
| 22:10 | <michaelficarra> | ljharb: those were arbitrary choices and you know it |
| 22:10 | <keith_miller> | lol |
| 22:10 | <ljharb> | perhaps so |
| 22:10 | <michaelficarra> | if we had considered that future committee might base a decision on it, we definitely would have made keys the canonical one |
| 22:10 | <ljharb> | but i also don't agree with the mental model that set elements are analogous to map keys (altho i recognize it's a valid model) |
| 22:10 | <keith_miller> | Not if I do Set.prototype.keys.name = keys |
| 22:10 | <keith_miller> | `Set.prototype.keys.name = "keys"` |
| 22:10 | <ljharb> | a Set is a list. that it has O(1) lookup doesn't make it have keys ¯\_(ツ)_/¯ |
| 22:11 | <michaelficarra> | ljharb: it's unordered, so it's a bag |
| 22:11 | <ljharb> | in JS it's quite ordered |
| 22:11 | <michaelficarra> | with uniqueness |
| 22:11 | <michaelficarra> | sure, JS sets are ordered |
| 22:11 | <Bakkot> | it's not a list because it's unique |
| 22:11 | <keith_miller> | yeah, it's definitely ordered in JS, which we should reconsider because memory |
| 22:11 | <Bakkot> | uniqueness = not a list |
| 22:11 | <keith_miller> | maybe needs to be a different type tho |
| 22:11 | <ljharb> | sure, but conceptually i think most JS devs think of sets as having values. |
| 22:11 | <rkirsling> | I mean in math sets have elements, and if you don't use a Set, then you effectively use a Map<T, bool> |
| 22:12 | <ljharb> | certainly there are domains where that mental model is the one that makes sense |
| 22:12 | <rkirsling> | so there's no precedent for calling them values, but it's also not to say that it's awkward to call them values |
| 22:12 | <shu> | i mean, the vox populi can also be wrong |
| 22:13 | <ljharb> | very true, but we still chose not to say mean things about ASI :-p |
| 22:14 | <rickbutton> | maybe not in the spec but I'll subtweet ASI all day |
| 22:14 | <Bakkot> | we shouldn't shame people for disagreeing with us but we can still take positions on things |
| 22:15 | <ljharb> | sure. but i don't think we're going to get consensus on a position that "sets have keys" |
| 22:15 | <haxjs> | agree with ljharb :P though i also understand why professional programmers would agree it's key ... hard to say which side is much "correct" :-P |
| 22:15 | <ljharb> | JS devs are professional programmers too. |
| 22:16 | <rickbutton> | neither is more correct, words have no meaning, the goal should be to satisfy the expectations of the developer (on average) |
| 22:16 | <michaelficarra> | keith_miller: btw this topic that Mark is asking about is exactly what I was talking about earlier |
| 22:16 | <keith_miller> | I missed it... |
| 22:16 | <rkirsling> | I mean given that we chose not to call it `elements`, it made sense to have `values` alias `keys` |
| 22:17 | <michaelficarra> | keith_miller: uggghhhh |
| 22:17 | <keith_miller> | sorry! |
| 22:17 | <rkirsling> | ...and it's fine that it's actually the reverse, _so long as_ we never require a user to know that |
| 22:17 | <ljharb> | rkirsling: the "so long as" isn't something we have consensus on either :-) |
| 22:17 | <haxjs> | ljharb: sorry, i mean senior devs may be more sensitive to some semantic attribute like "unique", so think it as key. |
| 22:17 | <michaelficarra> | keith_miller: whether you extend functionality by overriding some "core" set of methods or having to override every method, including any new ones added later |
| 22:18 | <keith_miller> | ah yeah |
| 22:18 | <michaelficarra> | there are pros and cons to each |
| 22:18 | <michaelficarra> | and we go back and forth constantly |
| 22:18 | <ljharb> | haxjs: perhaps. but i also know plenty of senior devs who think of it as having values. seniority doesn't require familiarity with advanced math concepts. |
| 22:18 | <keith_miller> | true lol |
| 22:18 | <michaelficarra> | ljharb: honestly it's probably more about formal education than years of experience |
| 22:18 | <ljharb> | perhaps so |
| 22:19 | <rickbutton> | I refer back to "words have no meaning" |
| 22:19 | <michaelficarra> | certain things, especially naming, are just passed down that way |
| 22:19 | <ljharb> | seniority and professionalism also do not require formal education. |
| 22:19 | <rkirsling> | agree |
| 22:19 | <Bakkot> | we should just pick random strings whenever this comes up |
| 22:19 | <rkirsling> | seniority seems irrelevant in this conversation |
| 22:19 | <Bakkot> | echo pwgen >> spec.emu |
| 22:19 | <ljharb> | right |
| 22:19 | <haxjs> | ljharb: sorry it's hard to express my meaning in accurate english word due to my poor english level... |
| 22:19 | <ljharb> | haxjs: nah i think i got what you meant! just wanted to clarify :-) |
| 22:20 | <shu> | words have so many meanings what you talkin about |
| 22:20 | <ljharb> | but yeah i think both are valid mental models. |
| 22:22 | <keith_miller> | Yeah I think keys vs values comes down to whether you took a bunch of abstract math clases |
| 22:22 | <keith_miller> | before learning to program |
| 22:23 | <rkirsling> | or well, just intro to discrete math really |
| 22:23 | <keith_miller> | at least that's probably why I see set as a typedef of Map<Type,unit> |
| 22:23 | <keith_miller> | discrete yeah |
| 22:23 | <keith_miller> | that's what I meant lol |
| 22:23 | <rkirsling> | but whether you've learned what a set is in school |
| 22:23 | <rkirsling> | and yeah "unit" would be more correct, I'm just thinking of it in terms of like |
| 22:24 | <rkirsling> | from a purely JS standpoint, even after Set was first available, it was still more common to do like |
| 22:24 | <michaelficarra> | yeah Unit is correct, I saw both Void and Boolean earlier and refrained from commenting |
| 22:24 | <rkirsling> | `{ key1: true, key2: false }` |
| 22:24 | <rkirsling> | err |
| 22:25 | <rkirsling> | `{ key1: true, key2: true }` |
| 22:25 | <haxjs> | I tend to support jordan's solution, allow any of it, but if provide both for Set, and not the same function reference, throw error... |
| 22:25 | <rkirsling> | my fingers keep making weird typos today |
| 22:26 | <haxjs> | Ooops, PLAIN date again? It's previous discussion decide to drop "plain" prefix? |
| 22:26 | <haxjs> | Isn't |
| 22:27 | <ljharb> | it's been PlainDate for awhile i think |
| 22:27 | <Bakkot> | https://github.com/tc39/proposal-temporal/issues/1072 |
| 22:28 | <haxjs> | So I miss that part... don't remember it been talked in the meeting, maybe I was sleeping in that meeting?? |
| 22:28 | <ljharb> | i doubt it was talked about in the meeting |
| 22:30 | <Bakkot> | I am in favor of just outright dropping subclassing support from this proposal |
| 22:30 | <Bakkot> | of all kinds, not just species |
| 22:30 | <michaelficarra> | agreed ^ |
| 22:31 | <michaelficarra> | until we have better motivation for it and a better plan for extensibility of built-ins in general |
| 22:31 | <haxjs> | though it's solely a bikeshed issue ,but I feel it's not very common to subvert previous decision without discussion in the plenary. |
| 22:32 | <haxjs> | Oh it seems the decision is based on twitter counts? 🤪 |
| 22:33 | <haxjs> | I remember many delegates don't like such thing? |
| 22:38 | <ljharb> | littledan: agree that it's unfair to put it all on Temporal; but when the existing pattern is "sometimes" i don't think it's a stretch to claim it's inconsistently applied |
| 22:38 | <keith_miller> | regexp... regexp is the worst lol |
| 22:38 | <shu> | Bakkot: yes, ofc me too |
| 22:38 | <shu> | especially because it's a group of classes all interacting |
| 22:38 | <Bakkot> | I think there's a good argument for this proposal being unique in this regar: it is a collection of classes |
| 22:38 | <Bakkot> | yeah, that |
| 22:39 | <ljharb> | right |
| 22:39 | <Bakkot> | anyway that's my queue item up next |
| 22:39 | <michaelficarra> | I'm very happy we're at least starting this conversation right now |
| 22:40 | <michaelficarra> | like, beaming |
| 22:40 | <michaelficarra> | and everyone is being very thoughtful and respectful :-) |
| 22:40 | <ljharb> | Bakkot: do you mean like, "throw if `new.target` isn't the base class"? |
| 22:40 | <shu> | i think that part is "fine" |
| 22:41 | <ljharb> | which part |
| 22:41 | <shu> | but i want methods to just do Construct(%Temporal.Foo%) |
| 22:41 | <ljharb> | right but that would mean we couldn't add subclassing later, if that's what we decide to do |
| 22:41 | <shu> | ljharb: i was saying the fact that you can type "new (class foo extends Temporal.Foo {})" and doesn't throw seems "fine" |
| 22:41 | <ljharb> | because people would have made subclasses and relied on it producing a base class instance |
| 22:41 | <littledan> | ljharb: I don't think our pattern is "sometimes". We have different analyses of what JavaScript has right now. You were conflating protocols and implementations in your listing. |
| 22:41 | <ljharb> | whereas if it throws, then nobody can have possibly made a base class until we're ready to let them |
| 22:42 | <shu> | ljharb: DOM heavily depends on that kind of subclassing |
| 22:42 | <shu> | the magic method instance creation, not so much |
| 22:42 | <ljharb> | shu: right but temporal isn't dom |
| 22:42 | <ljharb> | littledan: hm, ok. surely worth trying to get all of us on the same page about that analysis |
| 22:42 | <shu> | yes, that's true, and part of Bakkot's argument |
| 22:42 | <littledan> | I'd be up for removing @@species in Temporal, but there's a ton of other stuff going on in the TimeZone and Calendar protocols... |
| 22:42 | <ljharb> | littledan: if i can be made to understand that there is in fact a currently applied consistent mental model then that would be really helpful |
| 22:43 | <littledan> | well, I mean, we discussed it last meeting; I'm not sure what more to discuss |
| 22:43 | <littledan> | people proposed new possible changes, but I described what we do today |
| 22:44 | <ljharb> | let's find a time to discuss offline; what you described in the last meeting isn't a consistent model to my understanding, so perhaps there's something i'm missing |
| 22:46 | <michaelficarra> | ystartsev: I think the "cautious" route is actually not supporting any kind of extensibility until we have a clearer plan |
| 22:46 | <shu> | ystartsev: i also think the cautious route isn't actually web compat |
| 22:46 | <shu> | wait, no |
| 22:46 | <shu> | it's fine |
| 22:46 | <Bakkot> | ystartsev shu: to be clear I was only making an argument for what we should do with _this_ proposal, not for other cases, so there's no potential web compat issue |
| 22:46 | <shu> | right, yes |
| 22:47 | <shu> | wait, it can't be a SyntaxError |
| 22:47 | <shu> | it can be a TypeError or something |
| 22:47 | <ystartsev> | tbf i am multitasking so i was a bit surprised by the question. I need to think about it more, and don't have a confident answer yet. |
| 22:47 | <michaelficarra> | I don't understand, what syntax error? |
| 22:47 | <shu> | misunderstanding sounds like |
| 22:47 | <shu> | runtime error |
| 22:48 | <Bakkot> | I would kind of lean towards not making it an error but only very weakly |
| 22:48 | <haxjs> | Can I ask how to make it runtime error? |
| 22:48 | <shu> | i want extends to work, still, but i don't really have a good reason |
| 22:48 | <Bakkot> | haxjs: you say "if new.target is not [the right thing], throw" |
| 22:48 | <littledan> | I started a broader thread about hooks and optimizability, to speak more to Yulia's point. I really think that it will be hard to make the more non-trivial tradeoffs (beyond @@species) in the air, and it's better to make the tradeoffs in the context of an implementation that is developed. https://github.com/tc39/proposal-temporal/issues/1432 |
| 22:49 | <Bakkot> | haxjs concretely, see step 1 of https://tc39.es/proposal-temporal/#sec-temporal.plaindate |
| 22:49 | <shu> | littledan: let's separate the "hooks is the future" thread and the "how possible is Stage 3 for Temporal that removes all subclassing and have no hooks" |
| 22:49 | <Bakkot> | it would change to `If NewTarget is not %Temporal.PlainDate%` |
| 22:49 | <littledan> | I kinda feel like we might as well let extends work, just not do anything in particular to make it work *well* (like use the constructor of instances) |
| 22:49 | <ljharb> | shu: i would argue that extends doesn't work, if methods don't produce subclass instances |
| 22:50 | <haxjs> | Intesting, but could people still use old ES5 way to make it work? |
| 22:50 | <littledan> | Ujjwal just answered Richard's question |
| 22:50 | <Bakkot> | haxjs no, these can't be called without `new` |
| 22:51 | <Bakkot> | or, maybe I don't know what you mean by "the old ES5 way" |
| 22:51 | <rickbutton> | isn't the answer that "stage 3 is not 'ship' it's 'implement'"? |
| 22:51 | <ljharb> | haxjs: `new.target` works the same way in ES5 constructors, and can constrain them the same |
| 22:51 | <ljharb> | rickbutton: it's both |
| 22:51 | <Bakkot> | yeah, it has to ship before stage 4 |
| 22:51 | <michaelficarra> | rickbutton: no, we usually mean ship |
| 22:51 | <rickbutton> | do we mean ship behind flag or ship unflagged? |
| 22:51 | <ljharb> | rickbutton: engines are free to ship without a flag immediately once it hits stage 3, and are encouraged to do this quickly (not necessarily encouraged to lack a flag, ofc) |
| 22:52 | <rickbutton> | ok |
| 22:52 | <ljharb> | rickbutton: stage 4 requires 2 unflagged |
| 22:52 | <michaelficarra> | depends on the proposal, but we usually want web compat feedback, not just implementability feedback |
| 22:52 | <rickbutton> | right, makes sense, thx |
| 22:52 | <haxjs> | I mean u can just get the instance, change the prototype? |
| 22:53 | <ljharb> | rickbutton: in general any time there's an observable change after stage 3 advancement, it's either motivated by web compat, implementability, or we should have caught it before stage 3 |
| 22:53 | <ljharb> | haxjs: sure, but that's fine, that's not proper subclassing |
| 22:54 | <haxjs> | "we should have caught it before stage 3" --- what if we failed to caught it ? |
| 22:55 | <michaelficarra> | I'm also thankful that the champions chose an appropriate timebox for this topic |
| 22:55 | <ljharb> | haxjs: then we may, or may not, be able to change it |
| 22:55 | <ljharb> | haxjs: but that's why the risk of that kind of changes is supposed to be effectively zero before stage 3 advancement |
| 22:56 | <shu> | rickbutton: "shipped" simpliciter usually means "unflagged" |
| 22:56 | <rickbutton> | 👍 |
| 23:00 | <michaelficarra> | did they think they had to define a total ordering? |
| 23:00 | <michaelficarra> | a partial ordering seems fine |
| 23:01 | <ljharb> | Bakkot: https://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html says "It is strongly recommended (though not required) that natural orderings be consistent with equals." |
| 23:01 | <michaelficarra> | ljharb: partial ordering can still be consistent |
| 23:01 | <ljharb> | iow yes, it's not required there, but it's also not "wrong" |
| 23:01 | <Bakkot> | ljharb it also says "One exception is java.math.BigDecimal, whose natural ordering equates BigDecimal objects with equal values and different precisions (such as 4.0 and 4.00)." |
| 23:01 | <ljharb> | sure |
| 23:01 | <Bakkot> | which is exactly this case: |
| 23:02 | <Bakkot> | the points are the same on the line in question, they just have extra data |
| 23:02 | <Bakkot> | so the sort the same, but are not equal |
| 23:02 | <ljharb> | Bakkot: ftr i think your example is very compelling, where sorting would give you the wrong timeline order. |
| 23:02 | <Bakkot> | *they sort the same |
| 23:02 | <ljharb> | and obviously you can write all sorts of comparators that return 0 for two unequal things |
| 23:04 | <Bakkot> | yeah I mean it is true that it is usually a good idea for them to agree |
| 23:04 | <Bakkot> | just that it isn't a hard requirement, and I think that cases like this are exactly where the requirement should be violated |
