- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 Apr 2018 12:13:19 +0000
- To: public-houdini-archive@w3.org
The Working Group just discussed `Generator vs. Promise design for the API`, and agreed to the following resolutions: * `RESOLVED: We will continue adopting generators for layout functions.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Generator vs. Promise design for the API<br> <dael> github: https://github.com/w3c/css-houdini-drafts/issues/750<br> <dael> iank_: From the author PoV...<br> <dael> Rossen: The only difference is you added a *<br> <dael> dbaron: You need an async in the second line.<br> <dael> iank_: True.<br> <dael> iank_: These are the pros and cons [futher down the issue]<br> <dael> iank_: If anyone else has something to add here, I'll come back to the next meeting with data.<br> <dael> Rossen: Are generators broadly impl?<br> <dael> iank_: Yes.<br> <dael> iank_: Everyone does generators, though they haven't been used like this before.<br> <dael> TabAtkins: We won't expose the functions you can't run.<br> <dael> iank_: We'll have to make sure in the future. We have to code with eyes open.<br> <dael> fremy: You like this better because you can only allow some things to be sent?<br> <dael> iank_: It makes a tighter API. Promises are more familiar.<br> <dael> fremy: Dev are familiar with converting in the background<br> <dael> dbaron: After thinking about this, I'm feeling like the way devs interface with the engine here feels better desc by generator and not promise.<br> <dael> dbaron: I think because promises have this tie to an event loop thing where promises are running async on this micro-task. You're in the middle of this thing in the layout engine and it needs to call you many times.<br> <dael> ??: I agree you're generating the list<br> <gsnedders> s/??/surma/<br> <dael> TabAtkins: You're not though. We can call you fresh.<br> <dael> surma: That's details. Conceptually it works as a generator.<br> <dael> surma: I'm wondering if there's a place where scheduling with rpomises may become and issue and it wouldn't wiht promises.<br> <dael> iank_: I think there's work in FF to work promises at the right time. For the syncronous engines we would all the layout engine, make sure task queue is exhausted, make sure we've got a promise.<br> <dael> surma: It makes more sense with generators even if it's 100% correct.<br> <dael> dbaron: I think one of the weird things about generator is it produces the last thing at the end. You're using yield and return syntax to do much deeper things.<br> <dael> TabAtkins: The yield at the top of the issue is not usefully yielding into the engine. It's saying do this layout and give me results. It's using a generator as an async iterator. It's possible, but not the preferred pattern.<br> <dael> TabAtkins: It off doing it's own thing. If it was synchronous we wouldn't have to do this.<br> <dael> surma: Both allow us to think about async and parallel layouts in the future?<br> <dael> iank_: Yeah.<br> <dael> Rossen: I'm hearing mostly people leaning word generators.<br> <dael> TabAtkins: No.<br> <dael> Rossen: Except TabAtkins.<br> <dael> iank_: We can also give two different versions and see what people expect<br> <dael> Rossen: TabAtkins would you object? Any objections?<br> <dael> TabAtkins: I have weak objection and would like wider review.<br> <dael> Rossen: Has there been review? TAG looked, did they say anything?<br> <dael> Rossen: I went through Travis's comments and they were high level.<br> <dael> dbaron: I don't remember this one.<br> <dael> iank_: I think notes from the TAG meeting are up.<br> <dael> [everyone hunts meeting notes from TAG]<br> <dael> dbaron: Minutes say "Travis: I have some review feedback to post to the issue."<br> <dael> dbaron: We came back to it the next day, though.<br> <dbaron> TAG minutes in https://github.com/w3ctag/meetings/blob/gh-pages/2018/04-tokyo/04-06-minutes.md<br> <dael> iank_: [skim-reads]<br> <dael> Rossen: There's a couple ways to get out. 1) We agree to adopt promise-based API 2) We stick with generators with a light objection from TabAtkins and then he can figure out if we should avoid it. If he comes back with reasons and we can change.<br> <dael> TabAtkins: I'll bother Dominic<br> <dael> Rossen: Sticking with Generators will force the discussion.<br> <dael> Rossen: Do we have people that object to promise-based APIs?<br> <dael> TabAtkins: Performance aspect<br> <dael> iank_: I want to do some benchmarking<br> <dael> iank_: I think layout will be particularly sensitive to bindings.<br> <dael> TabAtkins: My hope is we don't need to re-apply promises.<br> <dael> iank_: We might need special APIs.<br> <dael> iank_: I'll have everything hopefully done.<br> <dael> Rossen: Prop: We will continue adopting generators for layout functions. TabAtkins will followup<br> <dael> RESOLVED: We will continue adopting generators for layout functions.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/750#issuecomment-379730650 using your GitHub account
Received on Monday, 9 April 2018 12:13:21 UTC