- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Aug 2018 18:19:43 +0000
- To: public-houdini-archive@w3.org
_From @dbaron on April 9, 2018 14:3_ The rest of the discussion ended with one resolution: * RESOLVED: introduce 2 classes as a mean to listing stateful and stateless types <details><summary>See the full IRC log</summary> <dbaron> Topic: Animation Worklets, continued<br> <dael> iank_: You can't look at the shape of arguments.<br> <dael> Rossen: Your versioning becomes crazy.<br> <dael> birtles: It's common in JS libraries.<br> <dbaron> github: https://github.com/WICG/animation-worklet/issues/87<br> <dael> iank_: Are you switching inside of native code here?<br> <dael> iank_: When you call the register animation, you're looking for arguments, that doesn't work. That's not failable.<br> <dael> birtles: Call .legth<br> <dael> majidvp: If you call .length it gives you number of required params<br> <dael> majidvp: If you have opional parameters, in webIDL at least.<br> <dael> birtles: There's another option further down<br> <dael> majidvp: I don't think second is possible. Can you differentiate between class and function?<br> <dael> TabAtkins: No, class returns a fuction<br> <dael> smfr: I think check is constructbale?<br> <dael> majidvp: Any is constructable<br> <dael> gsnedders: Not in webIDL<br> <dael> majidvp: This is user provided.<br> <dael> birtles: Point I was trying to make is that we don't nec need an attribute.<br> <gsnedders> gsnedders: then it does have construct<br> <dael> Rossen: Checking number of arguments is defined. You can check the length.<br> <dael> shane: I think there is a more desciplined argument about having it as a param because it's clear to people making the code.<br> <dael> birtles: I think it's quite intuitive to check the callback function<br> <dael> Rossen: One of the versioning schemas we have in our API is based on number of parameters<br> <dael> shane: It's a technique. But we're designing an API. It's bad design to change fundimentally different behaviors based on magic.<br> <fremy> q+<br> <dael> birtles: I hear you, but I see it so much I think it's idomatic.<br> <Rossen> a/in our API is based/in our ABI is based/<br> <dael> fremy: Relying on number or arguments is a problem when you need state and it's in the constructor...people use [missed] and if you don't put something in the argument it throws an error. Also if we ever need a 3rd argument in the future you're screwed. Maybe we have a default value so if you have that you don't need to do anything special.<br> <dbaron> Topic: Animation Worklets, continued<br> <fremy> q-<br> <dbaron> github: https://github.com/WICG/animation-worklet/issues/87<br> <dael> iank_: It works on top of the class, but if you extend something it doesn't work.<br> <dael> majidvp: Number of arguments works in webIDL because it has syntax to say which params are optional. normal JS doesn't have that concept. When you call a function at run time you know # arguments passed through. You use that to choose one behavior or another. As an engine I think you'll have a hard time.<br> <dael> shane: THe experiment from iank_ shows you can't do it at top level.<br> <dael> birtles: I'm not sure we want to decide now, it's discussion to have.<br> <dael> Rossen: One of the things...the whole discussion was do we need the attribute or not.<br> <dael> shane: Isn't going back to the issue likely to push it to the WICG?<br> <dael> birtles: We can take it offline.<br> <dael> shane: F2F is when we do things in person.<br> <dael> birtles: WEdnesday afternoon, then, during the breakout?<br> <dael> shane: You want to think about it more.<br> <dael> Rossen: Let's summarize. we don't want the attribute. To avoid that we can pass the info throught he param list and base the statefulness on that. That was mildly argued against since it's not clean design from internal API, though it's common for JS developers.<br> <dael> Rossen: We can resolve on nothing and keep the param for now, or we fast forward and resolve on the parameter and then bring other ways to do this if it's hard to impl or bad behavior.<br> <dbaron> FWIW, IRC bot issues: https://github.com/dbaron/wgmeeting-github-ircbot/issues/27 and https://github.com/dbaron/wgmeeting-github-ircbot/issues/28<br> <dael> Rossen: What do we want to do. Stay with static or number of param on construction<br> <dael> smfr: Two super classes was an option.<br> <dael> majidvp: We haven't discussed that<br> <dael> flackr: If statefullness defaulted to stateless when not spec you get behavior that you want.<br> <dael> majidvp: Which is a good default to have<br> <dael> shane: There's no signal it's a sure thing. I think you're expecting a state and it doesn't appear. I think being explicit is more clear.<br> <dael> flackr: You could throw if there is no state.<br> <dael> shane: That would be okay....it covers knowledge.<br> <dael> Rossen: Going back to three choices, I liked the 3rd, have the stateful and stateless classes. It makes it one or the other and satisfies the pushback against the attribute.<br> <dael> Rossen: Going forward if we discuss again and have something better we can re-discuss. But let's not lose the opportunity to resolve<br> <dael> majidvp: The super class if you want to allow dynamic it doesn't allow for that<br> <dael> shane: Not just a third class?<br> <dael> majidvp: Okay....you're using a heavy hammer for something that could be an attribute. Attributes are very common.<br> <dael> shane: If thre's a state object and you're in stateless version it's there. If you do have the hybrid later you can have explicit functions for switching.<br> <dael> Rossen: You can always have a conversion function based on object data<br> <dael> majidvp: Okay...that's not bad. I buy having the state object as a super class and then have setters.<br> <dael> Rossen: Other opinions?<br> <dael> Rossen: Objections to introducing 2 classes as a mean to listing stateful and stateless types?<br> <dael> RESOLVED: introduce 2 classes as a mean to listing stateful and stateless types<br> </details> -- GitHub Notification of comment by majido Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/812#issuecomment-417053903 using your GitHub account
Received on Wednesday, 29 August 2018 18:19:45 UTC