Re: URLQuery / FormData

On Mon, Sep 9, 2013 at 10:03 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Sep 9, 2013 at 5:49 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Did you forget the reasoning for the current design?  It was quite
>> intentional - it was meant to create a MultiMap, which acts like a
>> normal Map if you interact with it naively using Map methods, but
>> which can also be interacted with (via getAll() and append()) in a way
>> that supports multiple values per key.
>
> Except in the current design get() returns the first entry, delete()
> removes all, set() only overwrites the first entry.

The delete() behavior of deleting all keys is necessary for the
Map-compat  - otherwise, you could call delete(foo) and then get(foo)
and get something back!  We couldn't come up with any particularly
good reasons to only delete a single value anyway, and the method
signature would have to be different from plain delete().

> The MultiMap idea didn't gain much interest

Maps are only now starting to get traction in specs, and that's
partially because I've been pushing them rather hard.  I think it's
far too early to call on MultiMap yet.

(And, from personal experience, multimaps are *very* useful.  I
*constantly* use them in Python, via "defaultdict(list)".)

> and it's also not really a
> MultiMap. It's an ordered list of name/value pairs. Is a MultiMap not
> unordered?

Of course not.  Map is ordered, and so is MultiMap.

>> In fact, now it should probably be a [MapClass] in WebIDL, with some
>> of its methods overridden.
>
> The types are incompatible. In particular, the names are not unique.

No, the names are unique if you recast the spec to be a single
name/value pair, where the value is a list.  This is purely an issue
of spec terminology.

~TJ

Received on Monday, 9 September 2013 17:15:55 UTC