make hooking into maplike and setlike methods easier

[heycam]

Currently the spec allows clear, delete, and set on a maplike interface (and add, clear, and delete on setlike interfaces) to be overridden, so that spec authors can add validation of inserted keys and values, and to respond to changes in the contents of the backing map or set.

The prose required to do this is a bit awkward. For example, to override set to add syntax checking for the key argument, you would need to write something like this:

The set(key, value) method on the Foo interface, when invoked, must run these steps:

1. If key does not contain a hyphen, then throw a TypeError.
2. Let keyArg be the result of converting key to an IDL value.
3. Let valueArg be the result of converting key to an IDL value.
4. Let result be the result of running the steps for a built-in maplike set function, with the context object as the this object, and with arguments keyArg and valueArg.
5. Return result.

I think it may be better to disallow overriding these methods, but instead to have some spec hooks that are invoked from the built-in add, clear, delete, and set functions. That way the spec author can remain in IDL value land and doesn't need to deal with invoking the built-in steps.

cc @frivoal

[bzbarsky]

Do we have any existing uses of such overriding? What do those look like?

[frivoal]

I have one where I'm trying to make a maplike when there keys used as strings are supposed to be syntactically valid css ident tokens. It looks exactly like the above, because it's @heycam who told me how to do it. (sorry, no link yet, I'm in the middle of writing the first draft of this spec, so it's not published anywhere yet).

Another similar example, in a published spec, but without the IDL written yet, would be: https://drafts.csswg.org/mediaqueries-5/#script-custom-mq

In either case, it would be possible to describe the effect of sticking syntactically invalid values into the map (you cannot use them from the css side, and putting it there was a waste), but it seems better to prevent them from being added to the map in the first place.

[tabatkins]

Ah, I was about to open an issue asking for this as well (or rather, asking if spec authors really were expected to copy/paste from the ES-ese of the algos currently in WebIDL, or if we could just manipulate the "map entries" in simpler spec prose).

My use-case is https://tabatkins.github.io/css-toggle/#dom, where I probably want to hook set/delete/clear to add an association between a CSSToggle and the CSSToggleMap it's in, so you can't put one object into multiple maps.

[domenic]

See also #254 wherein I propose making maplike/setlike backed by Infra. (Before Infra existed, I think.) It's a bit tricky because of how MapIterator and SetIterator work but I think it's doable, with enough elbow grease. Then you could get a usage experience similar to the more-recent ObservableArray, which should hopefully be quite pleasant.