Queue Feature Request

[Zach Boldyga]

Good insight. I wasn't aware that using an empty object in the Map.set
implementation would yield unique keys, but it makes sense... You mention
sub-linear time, but not constant? Is Map expected to have a lot of
collisions? It seems as if it would be fine, based on the spec, but I'll
run a benchmark to see where V8's map ops stand in comparison to the
external queue / deque libraries.

Is there any way to extend that to a deque with similar operation times? I
don't see anything out-of-box, but it looks like the map iterator keeps a
numerical index of the keys. Could this be used to allow an iterator in the
reverse direction? https://tc39.github.io/ecma262/#sec-createmapiterator ,
the MapNextIndex. Or is this index just meant to be a counter to check for
exhaustion of the iterator?

Assuming this Map approach is performant, I still think syntactic sugar
would be nice. Although, wrapping up a Map implementation in an alleged
Queue might be misleading.

Are there any discussions around including linked structures? Or maybe a
reversed Iterable for each iterable?



Best,

Zach Boldyga
Scalabull  |  Founder
1 (866) 846-8771 x 101

On Sat, Feb 25, 2017 at 3:27 PM, Oriol _ <oriol-bugzilla at hotmail.com> wrote:

> Hello,
>
> you can try using a Map with unique keys. Map operations are guaranteed to
> be sublinear on average, and new entries are added to the end.
>
> Then you only need a trivial wrapper for better abstraction:
>
> ```js
> class Queue {
>   constructor() {
>     this._map = new Map();
>   }
>   push(value) {
>     this._map.set({}, value);
>   }
>   pop() {
>     var first = this._map.entries().next();
>     if (first.done) return;
>     this._map.delete(first.value[0]);
>     return first.value[1];
>   }
>   get size() {
>     return this._map.size;
>   }
> }
> var q = new Queue();
> q.push(1);
> q.push(2);
> q.pop(); // 1
> q.push(3);
> q.pop(); // 2
> q.pop(); // 3
> q.pop(); // undefined
> ```
>
> -- Oriol
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170225/4c0586c2/attachment.html>