"Dictionaries must not be used as the type of an attribute or constant" -- why?

[LeaVerou]

I recently observed a case where an API became less usable because of this, so I was curious what's the rationale?

[annevk]

You'd have to keep them alive for the lifetime of the object the attribute is associated with, which isn't necessarily great as it would just be a normal mutable JavaScript object not necessarily representing the actual state of things (even if the actual state of things is immutable, say, as the object could be modified by any caller).

[domenic]

Also, a new copy would get created every time the getter steps run (when you convert the Web IDL dictionary into a JS object), so you'd have obj.attribute !== obj.attribute.

[annevk]

That we could mitigate with an improved (tm) [SameObject], aka [Cached]. To me the mutability is the main downside of this. It might well be that sanitizer would be better off exposing these as getters though, that's how we often expose such settings (e.g., on ShadowRoot).

[LeaVerou]

It might well be that sanitizer would be better off exposing these as getters though, that's how we often expose such settings (e.g., on ShadowRoot).

Wouldn't what @domenic said be true with a getter though? That you'd have obj.attribute !== obj.attribute?

[annevk]

@LeaVerou you'd have a getter per setting. E.g., shadowRoot.mode.

[LeaVerou]

@annevk In this case, the object properties are also objects though…

[annevk]

It seems ReadOnlyArray would fit a bunch, but AttributeMatchList is indeed tricky. In that case the snapshot approach they have taken might be the best. At least with that multiple consumers cannot end up confusing each other easily.