W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Web IDL maplike: Allow spec prose to specify how key-type should be compared?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 2 Mar 2015 15:08:20 -0800
Message-ID: <CAAWBYDDrG8CMbNPX+BGUZpr86dSaGYXwOxGmhuWiskAAqxfZDw@mail.gmail.com>
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.)

Received on Monday, 2 March 2015 23:09:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC