- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jun 2019 17:09:43 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Avoid StatefulAnimatior/StatelessAnimator superclass and use existence of state() function`, and agreed to the following: * `RESOLVED: accept majid's proposal to use a state() function's existence to detect statefulness, and drop the superclass check` <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: Avoid StatefulAnimatior/StatelessAnimator superclass and use existence of state() function<br> <TabAtkins> ScribeNick: TabAtkins<br> <Rossen_> github: https://github.com/w3c/css-houdini-drafts/issues/850<br> <TabAtkins> majidvp: Last year, we made a resolution on how to differentiate between stateful and statless animator<br> <TabAtkins> majidvp: Idea was to use two seaprte classes<br> <TabAtkins> majidvp: You inherit from whichever you want<br> <TabAtkins> majidvp: We lookeda t some different options: looking at property on aniamtor, o rlength of arguments, etc<br> <TabAtkins> majidvp: While trying to implement this, I realized there were complications<br> <TabAtkins> majidvp: So new idea I thinka ddresses the shortcomings<br> <TabAtkins> majidvp: Rather than requiring a superclass to be extended, we look at the existence of the state() function<br> <TabAtkins> majidvp: So if your animator implements the state() function, they're a stateful animator. If not, they're stateless.<br> <TabAtkins> majidvp: I think that's simpler. THe interface matches the contract.<br> <TabAtkins> majidvp: Problem with the superclasses is that it clashes with bringing your own class hierarchy.<br> <TabAtkins> majidvp: It'll cause people to just extend StatefulAnimator at the top of their hierarchy, which defeats the point.<br> <TabAtkins> majidvp: This seems more consistent with other worklets too - PaintWorklet and LayoutWorklet don't require extending a class.<br> <heycam> q+<br> <TabAtkins> AmeliaBR: An issue I see with that is that from a JS perspective, you can add a getter function on an instance.<br> <TabAtkins> AmeliaBR: I'm assuming you judge it at the registration stage.<br> <TabAtkins> AmeliaBR: What if you put one on the instance?<br> <TabAtkins> majidvp: Verify it at registration stage, like paint functions works.<br> <TabAtkins> majidvp: If you add state() later, it'll be ignored.<br> <TabAtkins> majidvp: We want it to be a single value at registration for the whole life.<br> <TabAtkins> TabAtkins: So like we'll do a Get on the class object, seeing if "state" returns a function, and make the decision based on that. This is similar to, say, Promises and .then()<br> <TabAtkins> AmeliaBR: I see some different examples, a state getter and a state method. So it's the method you're discussing?<br> <Rossen_> ack heycam<br> <TabAtkins> majidvp: yes<br> <heycam> https://tc39.es/ecma262/#sec-ordinaryhasinstance<br> <TabAtkins> heycam: In the first issue comment, you say the current superclass model we have to ask tc39 to add an operation, but I think it already exists.<br> <TabAtkins> majidvp: I started looking at this becuase I wasn't sure how to spec it, and AudioWorklet already does this, but they haven't correctly specced it.<br> <TabAtkins> majidvp: During that my new idea came up, and I think regardless of speccing, this is a better API design.<br> <TabAtkins> proposed resolution: accept majid's proposal to use a state() function's existence to detect statefulness, and drop the superclass check<br> <TabAtkins> RESOLVED: accept majid's proposal to use a state() function's existence to detect statefulness, and drop the superclass check<br> <TabAtkins> <br type=lunch><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/850#issuecomment-499964845 using your GitHub account
Received on Friday, 7 June 2019 17:09:45 UTC