Re: [css-houdini-drafts] [typed-om] Align array-likes with future plans

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