You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few places on the platform implementing the "multi-map" pattern, where:
the underlying values are lists of something
get() only returns the first value in the list
set() becomes set(key, ...values)
getAll(key) is added, returning the list
append(key, ...values) is added, adding/creating to the list
This allows users of the interface to pretend that it's a normal map with only a single value per key, but also properly interact with it as containing multiple values, without having to always treat it like a list. (This is currently used by URLSearchParams and StylePropertyMap.)
Problem is that maplike<> doesn't allow you to override get() to have the correct behavior.
We should probably actually define multimaps officially, because right now URL and TypedOM use slightly different definitions - URL doesn't make set() or append() n-ary, and just uses iterable<> (so that it can interweave different values for a single key with values for other keys; ?one=foo&two=bar&one=baz is important to preserve and reflect). I think this means we'd actually need two multimap forms - one for map<key, list<val>> (StylePropertyMap) and one for list<(key,val)> (URLSearchParams).
The text was updated successfully, but these errors were encountered:
Discussing with @domenic in IRC illuminates some more differences between the two forms - list<(key, val)> semantics will usually want to set() in-place, like URLSearchParams does, deleting all the entries beyond the first, and with that, making set() n-ary doesn't make very much sense. (Tho append() should still be n-ary.)
On the other hand, for the map<key, list<val>> semantics, regardless of whether you set in-place or do a remove/append, it makes sense to set() multiple values at once.
There are a few places on the platform implementing the "multi-map" pattern, where:
get()
only returns the first value in the listset()
becomesset(key, ...values)
getAll(key)
is added, returning the listappend(key, ...values)
is added, adding/creating to the listThis allows users of the interface to pretend that it's a normal map with only a single value per key, but also properly interact with it as containing multiple values, without having to always treat it like a list. (This is currently used by URLSearchParams and StylePropertyMap.)
Problem is that
maplike<>
doesn't allow you to overrideget()
to have the correct behavior.We should probably actually define multimaps officially, because right now URL and TypedOM use slightly different definitions - URL doesn't make
set()
orappend()
n-ary, and just usesiterable<>
(so that it can interweave different values for a single key with values for other keys;?one=foo&two=bar&one=baz
is important to preserve and reflect). I think this means we'd actually need two multimap forms - one formap<key, list<val>>
(StylePropertyMap) and one forlist<(key,val)>
(URLSearchParams).The text was updated successfully, but these errors were encountered: