Re: [whatwg/webidl] Maplike/setlike iterators shouldn't use MapIteratorPrototype/etc (Issue #1142)

> The main details to worry about are iteration order

As we discovered, I didn't get this right; using holes (as the ES spec does) gives an observably different behavior than not doing so (as Infra currently does): if a collection is mid-iteration, and something is removed from the beginning, using holes means you'll still visit every subsequent item; not using holes means you'll "skip ahead" over one item, since they all have their indexes shifted down by one.  This'll need fixing.

> coercing -0 to 0 in keys

The default impl of the mutation methods do this, and I already have requirements on what the mutation methods have to return; adding a SHOULD requirement to coerce -0 to 0 is reasonable to add as well. Will fix.

> My thinking is that WebIDL maplikes specify types more narrowly than ES Maps do, which might lead to wanting a different backing store. This is particularly relevant if there's ever a maplike which has only a small number of possible keys, which is a place where you'd really want to back it by something other than a hashmap.

Talking to our engineers at Chrome, it seems that our current maplike/setlike impls are all doing disparate things anyway, *not* sharing significant code with the ES Maps and Sets. So afaict this shouldn't be a big issue for Chrome, at least; we'll just continue using distinct code that's written to intentionally match Maps/Sets in behavior but without expectation of code-sharing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1142#issuecomment-1122748264
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1142/1122748264@github.com>