- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 20 Nov 2012 14:20:30 -0800
- To: "Mark S. Miller" <erights@google.com>
- Cc: "bugzilla@jessica.w3.org" <bugzilla@jessica.w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Tue, Nov 20, 2012 at 1:06 PM, Mark S. Miller <erights@google.com> wrote: > This is all very tricky and you may be able to make it work. But why? > Do you anticipate passing a multimap into a place that expects a map? > For these use cases, do you expect that the passer of the multimap > reliably intends to effectively pass only these "first" mappings per > key to the receiver? As I write this, it all seems crazy and > unreliable, and not a pattern we should encourage. Let's keep Map and > MultiMap as distinct types, and standardize only Map, WeakMap, and Set > this round. I think it's reasonable in some cases to use a MultiMap as a plain Map - for example, in URLQuery, you might not want to encode any duplicated keys. In that case, it's perfectly fine to have it act like a normal Map. However, it may be better to just let MultiMaps have a method to cast themselves into Maps. After all, there are already two distinct types of MultiMaps - ordered (Array) and unordered (Set) - the latter can't be treated as a Map since it lacks the concept of a "first" value. A more important quality is probably just being iterable, which both Map and MultiMap would have in the same way, so that may be sufficient. ~TJ
Received on Tuesday, 20 November 2012 22:21:19 UTC