W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: [Bug 20019] Support subclassing ES6 Map

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 20 Nov 2012 14:20:30 -0800
Message-ID: <CAAWBYDC0NkL1MEPOCdmaWf4hrMEUTdYp2XTtBudwi33Zd0dWTQ@mail.gmail.com>
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

Received on Tuesday, 20 November 2012 22:21:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:07 UTC