W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: URLQuery / FormData

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 Sep 2013 17:23:28 -0700
Message-ID: <CAAWBYDBoF214cV5qaAO1s6M2vehyiv=Jj260XKiS+BZ3DRJy5A@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Sep 9, 2013 at 4:15 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Sep 9, 2013 at 11:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> obj.get(name)
>> returning the first value.
>> obj.getAll(name) or obj.getMulti(name)
>> returning an array.
> The problem with this is that then get and delete are no longer
> describing similar kinds of operations. get only operates on the first
> matching value. delete operates on all matching values. set would
> under your proposal operate on the first value and destroy the rest.
> Or would it take an array of values as well?
> The mismatch between get/delete seems wrong and makes the API hard to
> understand. That's why I proposed the change.

There's no mismatch.  MultiMaps can just be used in two modes, for
convenience.  If used in the "single value per key" mode, get() and
delete() work together perfectly - they get the single value, or
delete the single value.  (If you're wrong in your assumption, and
there are actually multiple values, that's fine!  You can't see them
anyway, so deleting them is completely fine.)

If used in the "multiple values per key" mode, getAll() and delete()
work together perfectly - they get all the values, or delete all the

Same with set()/append() - when used in the single-value mode, set()
does exactly what you want; when used in the multiple-value mode,
append() does exactly what you want.

There's no replace() or deleteOne() methods, but that's okay for now -
they don't provide any new functionality, and they can be added later.

If you *mix* the modes, then yes, things can be slightly confusing.  Oh well?

>> As far as I can tell it should be possible to make this object fully
>> compatible with a Map.
> It seems fundamentally incompatible with a Map. E.g. a Map does not
> support checkboxes.

I don't think he means "it should just be a Map"; I believe Jonas
means it should be *compatible* with a Map, which it is in the current
spec (but it won't be after your proposed changes).

Received on Tuesday, 10 September 2013 00:24:15 UTC

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