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 07:59:17 +0000 (GMT)
To: domenic@domenicdenicola.com
Cc: bzbarsky@mozilla.com, public-webapps@w3.org
Message-id: <5123974.24981399622356387.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? Btw, IMO AsyncMap somehow should be standardized in ES7?

Dominic wrote:
>
> I don't understand how an AsyncMap "interface" (class) could exist and be generic---especially not as a language construct.
>
If we do not make it as a language construct, AsyncMap interface would be defined in SW space just for Cache interface and CacheList interface I guess.

> Things are asynchronous for a reason, e.g. they require I/O to happen. No generic class could encapsulate that knowledge.
Promise already abstracts that async operation. AsyncMap is just a Map that runs async. No more no less. It does get/set/... the entry exactly the same way as Map does but returning Promise that resolves with the value.

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

The "hook" should be provided by additional methods defined in the derived class, when necessary. Assuming we have AsyncMap (something like the following) ready as a language construct in ES,
// Syntax is in TypeScript
interface AsyncMap<K, V> {
  get<K>(key: K): Promise;
  has<K>(key: K): Promise;
  set<K>(key: K, val: V): Promise;
  clear(): Promise;
  delete(key: K): Promise;
  forEach(callback: Function, thisArg?: Object): void;
  items(): Promise;
  keys(): Promise;
  values(): Promise;
}

We can define Cache interface as:
interface Cache: AsyncMap { // AsyncMap<Request, Response>
  add(...requests:any[]) : Promise {
    // for each request in requests:
    //   fetch(request)
    //   set the entry(request, response) to the map object
  };
  // AsyncMap.prototype
};

.add(requests) is the place to define the algorithm to do certain async I/O and set the result to the underlying map object. AsyncMap.prototype methods are supposed to provide the generic *async* Map operations.

Isn't it a good idea to have generic asynchronous Map in JavaScript? It's all async and we have Promise now. WDYT?

--
Jungkee Song
Samsung Electronics 
Received on Friday, 9 May 2014 07:59:56 UTC

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