- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 2 Mar 2015 15:08:20 -0800
- To: David Dorwin <ddorwin@google.com>
- Cc: public-script-coord <public-script-coord@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Mon, Mar 2, 2015 at 2:28 PM, David Dorwin <ddorwin@google.com> wrote: > 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.) Given that this is backed by a Map, I don't think we can realistically do this until Maps gain the ability to specify a key comparator. (Same with Set.) ~TJ
Received on Monday, 2 March 2015 23:09:09 UTC