W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Maplike

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Sep 2013 13:10:04 -0700
Message-ID: <CAAWBYDAYGhxkq0PzhJTVtTeURKFbv6TDwPFd48Ak4MROnf-CEw@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Sep 13, 2013 at 9:10 AM, Chris Wilson <cwilso@google.com> wrote:
> Hey,
> I was exploring Maplike to use in the context of the Web MIDI API (which
> contains a pair of unordered, keyed collections of MIDI ports available to
> the UA), and I had a few questions I wanted to raise/ask the status of.
> First comment - the missing bits defining iterators in
> http://dev.w3.org/2006/webapi/WebIDL/#es-map-members is, of course, a little
> problematic, because I'll have to make something up.  Tab mentioned the ES
> spec has these defined; should I go there for the definitions?

You don't have to define anything yourself - the iteration will just
use the map entries that you already have to define.

> The second item is an explicit ask I have: Maps seem explicitly oriented
> toward read/write collections; aka, in order not to violate the definition
> of Map members, I will have to declare clear(), delete() and set() (and
> explicitly say they do nothing, as you shouldn't be able to "remove" MIDI
> ports, or some wiseass is going to ask how to restore them).
> My hope is that it's feasible to say that any readonly attribute whose value
> is a MapClass interface is automatically readonly with respect to the map
> itself, such that set/clear/delete all throw or silently fail or something.

I thought this was reasonable earlier, but I've found that it's not -
for example, for the Font Load Events API, I believe I want
document.fonts to be readonly, so people cant' replace the object, but
still allow additions/deletions.

Still, though some easy way to indicate that something is a "frozen"
Map/Set would be very appreciated.

Received on Friday, 13 September 2013 20:10:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC