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

On Fri, May 9, 2014 at 3:59 AM, 송정기 <jungkee.song@samsung.com> wrote:

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

If trying to match ES APIs, please use "entries", as "items" is not a
thing.


>   keys(): Promise;
>   values(): Promise;
> }
>

Pardon me if I've missed some important context, but why would keys, values
and entries return a Promise when the ES APIs of the same name return an
Iterator?

Rick