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:32:54 +0000
To: Jungkee Song <jungkees@gmail.com>, Boris Zbarsky <bzbarsky@mozilla.com>
CC: public-webapps <public-webapps@w3.org>
Message-ID: <c879d63523e14d64b40ac07719ff0b26@BN1PR05MB325.namprd05.prod.outlook.com>
From: Jungkee Song [mailto:jungkees@gmail.com] 

> 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 understand how an AsyncMap "interface" (class) could exist and be generic---especially not as a language construct.

Things are asynchronous for a reason, e.g. they require I/O to happen. No generic class could encapsulate that knowledge. E.g. what does the algorithm for `get` say in AsyncMap? For some async maps it will do file I/O; for others, network I/O; for others, they will ask the user for values. A definition for `get` in a generic AsyncMap would have to delegate to some kind of `get` hook, but that's pointless, since you already have a `get` hook, namely the `get` method you're in the middle of defining.

Received on Friday, 9 May 2014 04:33:34 UTC

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