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

On May 9, 2014 12:18 PM, "Boris Zbarsky" <bzbarsky@mozilla.com> wrote:
>
> I'm looking at
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-listhere.
>
> 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.
>

Right. We're defining an AsyncMap interface [1] which Cache interface and
CacheList interface are based off of. AsyncMap isn't spec'd yet in any
place than in the .ts file. A difficulty encountered is we don't have any
IDL construct for this yet. Any suggestion? Btw, IMO AsyncMap somehow
should be standardized in ES7?

> 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.
>

Note that we're heavily refining the Cache interfaces ATM.

[1]
https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts#L944

> -Boris
>