Designing a MultiMap (in DOM, would like to be consistent with ES)

Tab Atkins Jr. jackalmage at
Fri Nov 30 16:01:56 PST 2012

On Fri, Nov 30, 2012 at 3:53 PM, Mark S. Miller <erights at> wrote:
> On Fri, Nov 30, 2012 at 3:38 PM, Tab Atkins Jr. <jackalmage at> wrote:
>> Our approach is that MultiMap should be able to masquerade as a Map,
> This means that you're still trying to make MultiMap a subtype of Map,
> whether it is a subclass or not. That herring still seems pink. But
> I'll go with this premise below.

It's useful for URLQuery, where for a lot of cases you don't need the
MultiMap functionality, just a Map, but there are plenty of edge cases
(reasonably common ones) where you *do* need that functionality.  So,
best of both worlds - when you don't care, you can just treat it as a
Map.  When you do care, you're covered for that too.

I figure if it's useful for URLQuery, there's a decent change it's
useful for others, too, and it has only a small impact on the API.

>> For iterators, obviously keys() would only return unique keys.
> That seems to conflict with the spirit of the rest of your design.
> Continue to think of the MultiMap as an ordered list of k,v pairs.
> keys() should return all the successive k elements in order, including
> duplicates. values() does likewise for the v elements, and items()
> does likewise for the pairs. Everything is parallel, has the same
> cardinality and order, and zips up just fine.

That's possible, but it means that you can't iterate through keys()
and query the map with the values.  That may or may not be an issue.
I'm fine either way, but if we do that, we definitely want a secondary
items() iterator that groups the values together.


More information about the es-discuss mailing list