Re: [Bug 20019] Support subclassing ES6 Map

[+es-discuss]

Speaking only for myself at this point -- I do not recall MultiMap
previously being suggested to the committee.

I think adding a MultiMap API to ES7 is a good idea. Neither Map nor
MultiMap should be a subclass of the other, since neither is an LSP
subtype of the other.

Since Map and Set will be in ES6 and MultiMap is trivially
implementable from these, we can wait until we see some experimental
implementations before standardizing. Hence the ES7 target.

The issue of subclassing built-in types in general is interesting and
important. Whatever we do for this in general, we should not need to
make any special case for Map and MultiMap. In general, new built-in
abstractions should act as much possible as if they were implemented
by an ES6 class and exported by an ES6 module. (Likewise for old
build-in abstractions, but less will likely be possible for these.)

On Tue, Nov 20, 2012 at 10:23 AM,  <bugzilla@jessica.w3.org> wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20019
>
> Tab Atkins Jr. <jackalmage@gmail.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jackalmage@gmail.com
>
> --- Comment #1 from Tab Atkins Jr. <jackalmage@gmail.com> ---
> Note that URLQuery isn't strictly a Map - it's a MultiMap, where one key can
> map to multiple values.
>
> As such, we should probably check with tc39 to see if they have plans for a
> MultiMap API after Maps are fully adopted, and be consistent with that.
>
> If they don't, we should at least make sure that the Map functions act
> appropriately for a single-value Map, and have additional functions for
> treating as a MultiMap (as you say, make set() take only a single value, while
> add() adds more values).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>



-- 
    Cheers,
    --MarkM

Received on Tuesday, 20 November 2012 18:57:28 UTC