| 06:31 | <yusukesuzuki> | omg it's yusukesuzuki |
| 14:43 | <shu> | ljharb: what're the topics for discussion that needs 60m for https://github.com/tc39/proposal-dataview-get-set-uint8clamped? |
| 15:03 | <ljharb> | the same thing we talked about last time - adding the get method, whether as an alias or not. obv i hope I’m grossly overestimating the timebox :-) |
| 15:05 | <nicolo-ribaudo> | consensus by talking until when everybody else is exhausted |
| 15:22 | <shu> | the same thing we talked about last time - adding the get method, whether as an alias or not. obv i hope I’m grossly overestimating the timebox :-) |
| 15:22 | <shu> | i think we should be respectful of scheduled time and go with a good faith estimate |
| 15:23 | <shu> | like we could all be reserving 90mins just in case |
| 15:23 | <shu> | but we shouldn't |
| 15:24 | <ljharb> | it is a good faith estimate. |
| 15:26 | <shu> | you just said you're hopeful that you're "grossly overestimating"? |
| 15:26 | <ljharb> | hopeful doesn’t mean that I’m certain that’s the case. It’s just optimism. |
| 15:27 | <shu> | okay, i'll retract "good faith", i mean something like not estimating for worst case, but for average case |
| 15:28 | <ljharb> | i mean worst case is that we overflow 60m, which I’m concerned about doing. |
| 15:29 | <shu> | then i'll come back to the original question, what are the discussion topics here that'll take that amount of time? is there new info and arguments re: adding the get method? |
| 15:29 | <ljharb> | if the chairs need more time, they can reach out to me or whoever else, and ask to reduce timeboxes - I’m not sure why it’s a big issue at this point |
| 15:29 | <ljharb> | no new info, but i want us to get to a decision this plenary. |
| 15:30 | <ljharb> | new info would probably make it a much shorter discussion. |
| 15:32 | <shu> | it's a issue for me because i want plenary time to be productive |
| 17:00 | <bakkot> | I am excited for emplace but dminor you may want to consider a larger timebox |
| 17:00 | <bakkot> | I do think there's room for 60 minutes of productive discussion on that topic, given the size of the design space |
| 17:02 | <bakkot> | personally I like the direction you've proposed; I would call it getOrInit and then have a separate .compute((k, v, isPresent) => newV) function for doing the insert-or-update pattern (possibly in a follow-on proposal) |
| 17:03 | <bakkot> | the fact that getOrInit does not require you to create a throwaway object/closure makes it a lot more appealing than the thing currently in the proposal |
| 18:45 | <rbuckton> | I might suggest getOrAdd (or getOrInsert) and addOrUpdate (or setOrUpdate). "init" seems like the wrong term since this isn't initialization, per se. "compute" is also a fairly overloaded term. |
| 18:51 | <rbuckton> | ensure is also a term I regularly use for functions using this pattern. |
| 19:57 | <bakkot> | getOrInsert works just as well for me, but isn't it initialization? it's taking something which previously didn't exist (a mapping for a specific key) and causing it to exist. |
| 19:58 | <bakkot> | compute I was just copying from Java's method of the same name |
| 20:00 | <bakkot> | haskell has alter which... is basically as generic as possible |
| 20:09 | <rbuckton> | "initialization" just seems somewhat awkward if you potentially delete the value on the previous line: |
| 20:10 | <rbuckton> | computeIfAbsent/computeIfPresent. You need the second half of the method name for context. |
| 20:11 | <bakkot> | it has the bare compute as well https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#compute-K-java.util.function.BiFunction- |
| 20:13 | <rbuckton> | I suppose it does. I still contend it it's a fairly overloaded term. |
| 20:13 | <bakkot> | certainly agreed there |