- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Oct 2018 09:40:57 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Figure out Array-likes`, and agreed to the following: * `RESOLVED: Make TypedOM compatible with future Array-like plans, per #825.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Figure out Array-likes<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/825<br> <heycam> TabAtkins: so Typed OM has had a handful of array-like interfaces since the beginning<br> <heycam> ... been clashing with anne and domenic on how to handle these<br> <heycam> ... last week domenic and I sat down to look at plausible future plans<br> <heycam> ... for array-likes in the future, it should indeed be an Array subclass<br> <heycam> ... so Array.prototype stuff works, Array.isArray works<br> <heycam> ... and then at some point, either as just a spec concept, or possibly as an author facing API, there'll be a way to hook get/set indexes<br> <heycam> ... although they look like data properties, there is still some magic<br> <heycam> ... that intercepts a get/set so it can update length<br> <heycam> ... just set<br> <heycam> ... nothing specwise that stops us using that hook<br> <heycam> ... this has some implifications for the array-likes in typed OM<br> <heycam> ... in particular, there are 3 arrays-likes -- CSSMathArray<br> <bz> +q<br> <heycam> ... it's declared to descend from CSSStyleValue<br> <heycam> ... it's the array that hold calc arguments<br> <heycam> ... could switch this over to a new Array subclass<br> <heycam> ... the other two, CSSUnparsedValue -- for representing var()s -- and CSSTransformList -- which reps transform lists<br> <heycam> ... both are array-like and you can array index them<br> <heycam> ... there's are directly useful as values you can set to properties, so can't change them from being CSSStyleValue<br> <heycam> ... probably then we'll move the segments / functions to a property hanging off them, make them array-likes that inherit from Array<br> <heycam> ... and have hooks that do type checks to ensure only transform functions etc. are set<br> <heycam> ... in anticipation of this working later on, these will still have getter on them for now<br> <heycam> ... when we do switch to the real model, worked out in IDL, we can just remove that and there'll be very little if any behavior change<br> <heycam> ack bz<br> <heycam> bz: have you talked to JS engine implementors about this?<br> <heycam> TabAtkins: I talked to domenic and adam klein about this<br> <heycam> bz: in particular the idea of generically hooking set on arrays they're ok with?<br> <heycam> TabAtkins: we can do this right now<br> <heycam> bz: sort of<br> <heycam> ... it's very very special cased for length updates<br> <heycam> bz: in the TC39 spec handwaves it<br> <heycam> ... in impls for performance ...<br> <heycam> TabAtkins: so they wouldn't be naked Arrays with magical behavior<br> <heycam> ... right now indexed setters get the same array-loooking thing and they are optimized (not quite as good as naked arrays)<br> <heycam> bz: so you would be modifying Array.isArray to do something here<br> <heycam> TabAtkins: yes<br> <heycam> bz: and deal with subclass construction bits<br> <heycam> TabAtkins: domenic has some feedback in TC39 for this<br> <heycam> fremy: one question. the segments array in CSSUnparsedValue would not be read only?<br> <heycam> TabAtkins: it's not currently read only<br> <heycam> ... it only takes strings and var referecnes<br> <heycam> ... we'll continue doing type checking to make sure other values aren't set in there<br> <heycam> andrew: you don't want to make the transform components subclasses<br> <heycam> ... they have to descendt from array<br> <heycam> ... what do we do for values we return?<br> <heycam> TabAtkins: CSSTransformList remains a CSSStylevalue<br> <heycam> ... but it has a prop that is an array-like<br> <heycam> andrew: if you register a prop with that syntax<br> <heycam> TabAtkins: transform functions are CSSStyleValues as well<br> <heycam> ... the list inside it<br> <heycam> andrew: ok, misunderstood<br> <heycam> fremy: if we have the segments thing, it's better<br> <heycam> ... but there is still the case for when you upgrade CSSUnparsedValue to another thing<br> <heycam> ... you should not break the compat<br> <heycam> ... if right now we don't have a position thing<br> <heycam> TabAtkins: no, unparsed value is not the generic value class<br> <heycam> ... that's CSSStyleValue<br> <heycam> fremy: CSSUnparsedValue is only for var?<br> <heycam> TabAtkins: yes<br> <heycam> bz: what are the semantics of setting .length on these things?<br> <heycam> TabAtkins: still a great question<br> <heycam> ... not 100% sure, but more than likely I'll decide it's fine to have undefined/holes<br> <heycam> ... and those are ignored<br> <heycam> ... or truncates or whatever<br> <heycam> fremy: in the meanwhile can't we use a normal Array with no checking<br> <RRSAgent> logging to https://www.w3.org/2018/10/25-houdini-irc<br> <heycam> ... well it's not compatible with you switch<br> <heycam> bz: code that used to work will start throwing exceptions<br> <heycam> TabAtkins: this is detailed enough to know what the direction will be. let me know you thoughts<br> <TabAtkins> RESOLVED: Make TypedOM compatible with future Array-like plans, per #825.<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/825#issuecomment-432984928 using your GitHub account
Received on Thursday, 25 October 2018 09:40:58 UTC