Re: [css-houdini-drafts] [css-typed-om] Inputs for the CSSColorValue constructors (#1014)

> So all the changes you can think of are about syntax, not functionality?! 

No, I was just focusing on things that I might *change* from our current model. Things that would be useful to *add* could definitely be added!  In particular, *most* of the bullet points you listed are absolutely reasonable to go in Typed OM; a few are slightly more questionable for this API but definitely within the realm of possibility.

Just because the list is pretty long and getting off-topic for this issue, I've filed #1040 to track them.

> What do you mean by "magic tear-offs"?

Whenever an object has a sub-object that is intimately tied to it, so that manipulating the sub-object fiddles with the state of the super-object, it's a "tear-off". Compare to a sub-object that is just its own encapsulated state, which the super-object can reference at some well-defined time to do some operation.

A tear-off example is y'all's Color.js object, with its .rgb and .lab sub-objects, where the sub-objects are just "windows" into the Color object's state; any changes to the Color object are immediately reflected in the sub-objects, and mutating the sub-object immediately changes the Color object. You can't (I assume?) take the .rgb object from one Color instance and set it to another Color instance and get something useful out of that. 

A non-tear-off example is the current TypedOM classes. Some of them have sub-objects, like the list of transform components in CSSTransformValue. But they're not linked to each other in any intimate way; the super-object doesn't even look at the sub-objects until they're passed to .set(). Between those times, you can fiddle with either and the other is unaffected; if you reuse an transform component across multiple CSSTransformValue objects, that's fine. This is an important part of Typed OM objects being "not live" that we decided on very early.

Tear-offs have lifetime implications: the super- and sub-objects keep each other alive, and they have to maintain a 1:1 correspondence; this complicates implementation. Their behavior is often mildly confusing to authors and can cause subtle bugs, when authors don't anticipate the long-term connection they have with each other, and mutating one of them unexpectedly mutates the other. The sub-objects usually can't be constructed on their own; they only come as a package with the super-object.

(There are some cases which look kinda halfway between, but are for the most part in the "non" case, like URL and URLSearchParams. A URL object comes with its own URLSearchParams, which you can't replace. But they don't communicate with each other except when you actually *use* the URL, at which point it reads all of its attributes; they don't keep each other alive (if you just grab the URLSearchParams object and drop the URL, the URL can get collected safely); and you can construct independent URLSearchParams objects without referencing a URL at all.)

So, they're not verboten, they're just good to avoid when we can shape the API in another way. Sometimes they're unavoidable, but usually they're not.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-841387528 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 May 2021 17:17:14 UTC