00:04:42  * araijoined
00:11:05  * AtumTquit (Remote host closed the connection)
04:38:32  * jmdyckquit (Remote host closed the connection)
06:46:14  * oliverdunkjoined
06:47:07  <oliverdunk>Hi! I was wondering if anyone was aware of an existing proposal to adding something like Promise.clear()? I'm not looking to cancel the promise, but instead no longer want any code to execute after it resolves.
06:49:44  <arai>does it mean that the promise won't be resolved nor rejected?
06:53:49  <oliverdunk>@arai You could potentially add another .then callback afterwards, but it would just remove any added up to that point.
06:59:51  <arai>Is it for reducing memory pressure?
07:00:15  <arai>err, maybe I'm misunderstanding something
07:00:34  <oliverdunk>I have to head off but I'll check the logs and respond to any questions when I get back :)
07:00:57  * oliverdunkquit (Quit: Textual IRC Client: www.textualapp.com)
07:02:05  <arai>maybe undo-ing .then() and .catch() call?
07:08:20  <annevk>Pretty sure there's been no such thing proposed
07:33:23  * keith_millerjoined
07:36:27  * keith_millerquit (Remote host closed the connection)
07:37:14  * keith_millerjoined
07:59:07  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
08:26:10  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:37:37  * keith_millerjoined
08:57:50  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:02:11  * keith_millerjoined
09:06:02  * araiquit (Remote host closed the connection)
09:09:17  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:11:02  * keith_millerjoined
09:11:37  * keith_millerquit (Client Quit)
09:11:39  * JaseW_joined
09:12:08  * JaseW_changed nick to JaseW
09:13:54  * keith_millerjoined
09:19:18  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:25:07  * mylesborinsquit (Quit: farewell for now)
10:25:38  * mylesborinsjoined
11:12:55  * araijoined
13:09:49  * AtumTjoined
13:21:22  * jmdyckjoined
15:03:38  * jwaldenjoined
16:02:02  * oliverdunkjoined
16:02:42  <oliverdunk>@aria Exactly. I'm not sure yet if you would be able to remove individual blocks, or if .clear() would just remove all of them.
16:02:57  <oliverdunk>@arai I mean, apologies.
16:51:37  * oliverdunkquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:25:41  * oliverdunkjoined
17:26:07  <oliverdunk>Since it's quite quiet in here, would I be best writing something on the mailing list? New to the whole process :-)
17:29:38  <bterlson>oliverdunk: if the goal is to ultimately get a proposal in the pipeline, es-discuss can't hurt! You can also take a look at proposals on github and write up an explainer to help people understand the motivation and design.
17:30:49  <bterlson>process-wise: you're "stage -1" until you find a TC39 delegate-champion to bring it up at a meeting
17:35:47  * cloudshujoined
18:38:10  * srl295joined
19:14:57  <oliverdunk>https://www.ecma-international.org/ has been suspended?
19:15:13  <bterlson>oliverdunk: yeah, email sent, waiting to hear more
19:16:50  <oliverdunk>No problem. Thanks for your help above by the way - I wrote a brief proposal and put it on es-discuss, and having been getting some good feedback already.
19:17:45  <Domenic>Thoughts on how to handle promises in spec text welcome... https://github.com/MylesBorins/proposal-top-level-await/pull/15
19:18:43  <Domenic>caitp bterlson seem like people to help with ^
19:50:38  <Domenic>Gah this stuff breaks my brain now I'm not even sure there's a problem...
20:18:51  <Domenic>Moved to https://github.com/MylesBorins/proposal-top-level-await/issues/18, progress made
20:31:03  <Bakkot>oliverdunk: I don't think it's a good idea to add this in general - giving Bob access to a promise P shouldn't entail giving Bob the ability to interrupt Alice's previously attached listener to P
20:32:31  <oliverdunk>Bakkot: do you think the same about being able to remove a callback by passing a reference to the one that you want to remove? I understand what you're saying but that would be similar to removeEventListener.
20:33:42  <Bakkot>oliverdunk: removeEventListener currently requires you to have access to the callback you're trying to remove, and proposals to relax that requirement have been met with strong objections
20:34:53  <Bakkot>a proposal allowing you to remove a listener which you have a reference to would be a lot more palatable one than one which allows you to remove arbitrary listeners, I think
20:35:09  <oliverdunk>Ok, I think that is a fair compromise. Something like https://esdiscuss.org/topic/proposal-allow-promise-callbacks-to-be-removed#content-1 perhaps?
20:35:19  <Bakkot>(er, where 'listener' means 'thing passed to .then', I guess)
20:36:03  <Bakkot>Sure, something like that.
20:37:52  <oliverdunk>Ok, thanks. I can't see a situation where the "all seeing" clear method would be the only option, so I am open to that. Will leave a reply in the esdiscuss about this.
20:37:59  <Bakkot>Personally I'm not convinced that even that restricted functionality is necessarily desirable either, but it's a lot more likely to fly than the one allowing you to remove all listeners.
20:39:51  <oliverdunk>Is there a particular reason why you're against it? Hope you don't mind me asking just so that I can get a better understanding.
20:41:28  <Bakkot>No, of course please feel free to ask; give me a sec to try to articulate it
20:48:15  <TabAtkins>Guessing the basic objection is that you can just do this yourself; in your callback, check some boolean that the callback closed over, and if it's false just return immediately.
20:49:21  <TabAtkins>(Unlike event listeners, which might fire indefinitely, and thus you can reasonably want to remove unused callbacks so they don't just stack up over the lifetime of the page. Promise callbacks only fire once and then are done, so there's no extra cost outside of the interval between you wanting to remove it and the promise resolving.)
20:51:48  <TabAtkins>(I'll respond with this comment over on the thread, too.)
20:53:29  <Bakkot>It feels like it's putting the responsibility in the wrong place. Promises are mostly boxes with values in them, in my mental model, and `.then` is a way of turning a function from values to values into a function from boxes to boxes. This idea of "clearing" a `.then()` feels like you are asking to un-apply a function.
20:53:47  <Bakkot>yeah, also mostly what TabAtkins said, I guess.
20:55:58  <oliverdunk>I see. TabAtkins: I can see it as useful when you may want to add and remove it multiple times, e.g adding it when a user navigates to a particular page in an SPA, and removing it when they leave. You would need to keep track of if it was already added so that it isn't added twice.
20:56:48  <Domenic>I'm not sure why runMe = true | false is harder to do than p.(removeHandler | then)(handler)
20:57:53  <oliverdunk>You would need runMe and callbackAlreadyAdded. But I do see what you're saying.
20:58:11  <Domenic>The beautiful thing about runMe = true
20:58:16  <Domenic>Is that if it's already true, that doesn't impact anything
20:58:26  <Domenic>So it seems like you'd only need that
20:59:42  <oliverdunk>So runMe is storing both if it has been run and if a callback was added? It seems a bit messy but if this is going in a direction with promises that we don't want to, I will accept defeat.
21:00:06  <Domenic>Oh, well, it only ever runs once anyway, so if that's your concern, promises already have you covered.
21:02:16  <oliverdunk>I don't think I'm explaining properly, unless I'm just missing the point? What I mean is that if you add a callback to the same promise (which is taking forever to resolve) each time they return to a page, you will end up with multiple callbacks which are all fired simultaneously when it finally resolves, which all do the same thing.
21:03:51  <Domenic>Yeah, makes sense. Then this should work: `/* once */ let runMe = false; /* lots of times */ p.then(() => { if (!runMe) { return; } runMe = false; ... do stuff ... })`
21:03:57  <TabAtkins>Right. So you can either track whether you've added that yourself (in an alreadyAdded boolean in the outer script), or you can have each callback close over a runMe boolean, and set it to false on the previous before you add a new one. In the latter case they'll all fire when it finally resolves, but all but the last will just check the boolean and immediately stop.
21:04:08  <Domenic>Er, initial runMe should = true
21:04:22  <TabAtkins>Or what Domenic said, which seems easier. ^_^
21:10:32  <oliverdunk>I appreciate the feedback Domenic and TabAtkins. I think I'll lay this one to rest but I've learn a lot doing this; will make sure to come back when I have another idea.
21:11:46  <Domenic>:)
21:44:22  * oliverdunkquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:44:54  * not-an-aardvarkjoined
22:03:22  * keith_millerjoined
22:07:29  * keith_millerquit (Ping timeout: 248 seconds)
22:32:46  * keith_millerjoined
22:32:52  * keith_millerquit (Remote host closed the connection)
22:33:31  * keith_millerjoined
22:54:22  * araiquit (Ping timeout: 264 seconds)