- From: David Dorwin <ddorwin@google.com>
- Date: Mon, 2 Mar 2015 14:28:39 -0800
- To: public-script-coord <public-script-coord@w3.org>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>
- Message-ID: <CAHD2rshTd9OKvw7N7rLaS5mc=BjjAhae6vh1Qw6_32Bpk8h+6A@mail.gmail.com>
http://heycam.github.io/webidl/#es-maplike defines the behavior of maplike objects it in terms of delegation to an actual ES Map object. This means that if the key-type is an object, keys are compared by object ID rather than content. Thus, has() and get() will only return positive results if the same object that is stored is passed. This works for things like a Node, which the application could actually obtain, but it doesn't work for values that are represented by objects. Specifically, a value in a BufferSource. Should specifications be allowed to specify a different behavior in prose or should we force them to manually define the map methods? Should such non-compliant manual maps be discouraged? As a concrete example, for EME, we attempted to use a readonly maplike with a key-type of BufferSource, which contains a binary key ID. This can be made to work by comparing the value in the BufferSource, but this is not compliant with the maplike spec. (See the EME spec bug https://github.com/w3c/encrypted-media/issues/25 for more details.) If there is no change to the maplike spec to allow prose to modify the comparison behavior, EME will likely switch to a manually defined map-like interface. (We could also use a primitive type to represent the key ID, but that is inconsistent with other representations of binary data in the spec.) David
Received on Monday, 2 March 2015 22:29:26 UTC