Also I would love to use it in https://chromium-review.googlesource.com/c/525354/19/third_party/WebKit/Source/platform/loader/fetch/ResourceLoadScheduler.h instead of using HashMap and Deque

yutak: Would you take a look at this?

For many of these maps which are fairly small, flat vector storage (i.e., Vector<pair<key, value>>) with a nicer API might be more efficient than a linked hash map.

Worth considering multiple data structure choices for these uses.

In my use case of #1, it will contain thousands elements, but it may be exceptional case.

Maplike implementation could have such a common API that is internally realized by vector and provide an interface for maplike users, rather than adding it to wtf?

We already have a setlike one. Actually, two: ListHashSet and LinkedHashSet.

If I understand correctly, I think you can emulate a maplike by providing a
custom HashFunctions to LinkedHashSet.

I'm a bit hesitent to add a new HashTable-based container now, because its code
is pretty messy and I'm now in the process of refactoring it. In HashTable v2,
I can certainly consider introducing LinkedHashMap.

Re flat vector: if we need to keep doing lookups and mutations, it can easily
cause O(N^2)-time operations. O(N^2) is really bad and I'm against introducing
a container that can potentially lead to O(N^2) operations.

Upgrading from Untriaged to Available to get it out of the bindings triage queue.

yutak@, feel free to assign it to yourself or block on your HashTable v2 bug if you feel that's appropriate.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

IIUC, the current implementation looks a sort of #c4, IDL maplike's implementations need to implement blink::Maplike<KeyType, ValueType>.  The implementation can use Vector, LinkedHashSet, or anything else depending on the typical use cases and the typical size.  From PoV of bindings, this looks okay as is.

Thus I remove Blink>Bindings, but feel free to add it back.

Probably the implementations still want to use LinkedHashMap.  So, I leave this issue to be open.