I did a good thing a while ago: just stopped using Reddit.
It would be great to see the memory usage of each approach.
Thanks for comparing the different implementations! Yeah, clearly the SplicingQueue is the slowest.
"Then use splice if you're really concerned about it... will be O(n) with an n of 2."
enqueue() and dequeue() operations on a queue have to be O(1) time complexity. Using unshift(), splice() is a mistake, they are O(n).
Your proposal is to use an O(n) complexity function splice() instead of delete O(1) - but that's just a mistake.
"Also, have you actually measured the performance cost of Delete... as I mentioned, you're optimizing by using an expensive call."
delete operator is O(1) time complexity. That's all that matters.
this._items.shift() cannot be used because it's O(n) time complexity.
"Neither the original article [...] references any proposal to add this to the EcmaScript spec."
Plain wrong. Please go read the post again. It mentions: "Fortunately, a new proposal https://github.com/tc39/proposal-relative-indexing-method (at stage 3 as of January 2021) brings the method at() to arrays."
"but they want permission to "Act on my behalf" in Github"
Please go read about https://utteranc.es/ commenting system. "Act on my behalf" means that you allow Utterances app to comment in GitHub issues, but only in repositories that have installed Utterances app.
Look very interesting! Thanks for sharing.
Don't mix oranges with orange juice.
The post's sole purpose is to explain iterators in the most the accessible way. Generators are deliberately omitted because they're too complex, and, if mentioned, would introduce confusion to the reader.
I made a perf test that includes concat too: https://jsperf.com/spread-operator-head-vs-tail/13.
Seems like [item].concat(array) is the fastest.
Good idea. You will find this message in the conclusion of the post too.