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

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

From: 송정기 <jungkee.song@samsung.com>
Date: Fri, 09 May 2014 08:20:12 +0000 (GMT)
To: "bzbarsky@mozilla.com" <bzbarsky@mozilla.com>
Cc: "domenic@domenicdenicola.com" <domenic@domenicdenicola.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <7593350.25941399623611220.JavaMail.weblogic@epml20>
Jungkee wrote:
>> 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?

Boris wrote:
>
>
> What is the goal with AsyncMap in its generic form?  How will it actually reflect into ES?
>
Providing base interface for Cache interface and CacheList interface which largely conform to ES6 Map object. (But we aim to make everyting async within SW execution context.) Regarding the implication to ES, I have no idea. Not sure but no one has proposed this to TC39 yet and neither do we know if it makes much sense.

> Specifically, what does it actually do with the types it's parametrized over?  Do get/has/delete/set coerce the key to K?  Does set coerce the value to V?  And in ES terms, how is that reflected into actual ES objects?
>
Re the type coercion, I think it largely has to follow what the ES6 Map will do. I do not have any concrete idea yet indeed.

> -Boris
>



--
Jungkee Song
Samsung Electronics
Received on Friday, 9 May 2014 08:20:43 UTC

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