W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

RE: It doesn't make sense to use [MapClass] for the CacheList interface

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 9 May 2014 04:14:48 +0000
To: Boris Zbarsky <bzbarsky@mozilla.com>, public-webapps <public-webapps@w3.org>
Message-ID: <b1e57aa2ba6d478a977b7e15e0ea6900@BN1PR05MB325.namprd05.prod.outlook.com>
Agreed, this was odd to me.

As an aside, I filed https://github.com/heycam/webidl/issues/11 regarding [MapClass].

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mozilla.com] 
Sent: Thursday, May 8, 2014 23:15
To: public-webapps
Subject: It doesn't make sense to use [MapClass] for the CacheList interface

I'm looking at
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-list
here.

The point of [MapClass] (assuming [MapClass] stays in the WebIDL spec at
all) is to declare interfaces that quack enough like Map that it makes sense to have them be instanceof Map and have Map.prototype on their proto chain.

But as the "Issue" in the text notes, CacheList doesn't so much behave like a Map.  You put in Cache objects but get out Promise objects.  The
set() method doesn't return the object you called it on, but something completely different.  has() returns a different type from ES6 Map.

I don't think it's worth trying to use MapClass here; this just isn't a Map in any sense, though clearly it's somewhat related to one.

-Boris
Received on Friday, 9 May 2014 04:15:20 UTC

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