Re: [heycam/webidl] Figure-out what supporting Array-subclassing implies (#345)

To be specific here, the TypedOM use-cases are:

1. [CSSUnparsedValue](https://drafts.css-houdini.org/css-typed-om/#unparsedvalue-objects) - this is just a typechecked array-like, nothing more - the values must be DOMStrings or CSSVariableReferenceValues.

2. [CSSNumericArray](https://drafts.css-houdini.org/css-typed-om/#cssnumericarray) - same, it just restricts its values to be CSSNumericValues.

3. [CSSTransformValue](https://drafts.css-houdini.org/css-typed-om/#transformvalue-objects) - this one's more complicated. It restricts its values to be CSSTransformComponents, but also has an `is2D` getter (which consults the `is2D` flags on its contents and combines them) and a `toMatrix()` method (which calls `toMatrix()` on its contents and combines them).  This means it still doesn't actually have any state of its own besides the array-like contents.

All three of these are "dead" - updating them has no action-at-a-distance on anything else.  (You have to actually assign the object to a property manually, at which point it "snapshots" the object into an internal CSS value disconnected from the JS object.)

Two of these (CSSUnparsedValue and CSSTransformValue) are mutable; CSSNumericArray is readonly, both in its contents and the bindings that it's assigned to (to prevent cyclic values and some other inconsistencies from occurring).  This means it doesn't matter what sort of object is returned from `.map()` for CSSNumericArray, but for CSSUnparsedValue and CSSTransformValue we want to get the same type of object back, so it can be used directly again without having to manually pass the result to a constructor.

Wrt [Boris's questions from earlier in the thread](https://github.com/heycam/webidl/issues/345#issuecomment-294911678):

2. I don't have any writable attributes *yet*, but two of these types are subclasses of `CSSStyleValue`, which is the type accepted by `StylePropertyMap.set()`/`append()`.  *That's* the type that matters for us, not the array-ness of the value, so we do need a JS-idl conversion story; we can't just rely on `sequence<>` auto-conversion.  (And we will probably end up needing writable attributes at some point too, as we fill in more properties with special-purpose CSSStyleValue subtypes; as long as the types aren't recursive, there's no problem with making the lists writeable.)

3. The CSSTransformValue getter and method are currently written with the assumption that the contents are definitely going to be CSSTransformComponent objects; if they were applied to an arbitrary array the behavior is currently undefined.  I'm thus fine with brand-checking still applying; I'm not really sure why we wouldn't brand-check in general.

4. I'm not currently using any non-trivial internal slots on any of the classes. (That is, nothing beyond the implicit ones storing the contents and the original value of the methods, etc.)  I'm not sure if that'll change in the future as we introduce new array-likes, so I can't help with figuring out how to deal with them yet.

5. The operations obviously have to type-check.  The constructors and indexed setters already do; there's no justification for not type-checking on any other mutator.  There's an interesting question about *when* things are type-checked for `.map()` and similar - is it immediately as the callback returns each value, or at the end when an internal array of results is finally passed to the constructor? I have no opinion on this and don't think it matters for anything, so we can go with whatever's more convenient/sensible.

6. As I've said elsewhere, I think it's most reasonable for array-likes to iterate the same way that arrays do. (I'd *prefer* the set-like iteration, but I think consistency is more important.)

--------

Additionally, we probably want to require some consistency in the constructor/setter signatures - the primary constructor should always take a `sequence<>` (possibly with additional optional arguments), and the inner type of that `sequence<>` should be identical to the type of the indexed setter.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/345#issuecomment-361823673