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

Re: URLQuery / FormData

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 Sep 2013 00:31:18 +0200
Message-ID: <CA+c2ei-TY2AeqC9HsNvFRUyrzKdVETo_uD2eOiMj-5WRvzyD8w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Sep 9, 2013 at 11:23 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Sep 9, 2013 at 9:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Mon, Sep 9, 2013 at 1:30 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> * get(name) -- always returns an array, with ES6 destructering this
>>> should be fine
>> This seems like optimizing for the rare case.
> Given
>   [value] = obj.get(name)
> how is that a problem?
> What alternative API would you propose?


returning the first value.

obj.getAll(name) or obj.getMulti(name)

returning an array.

Ddestructuring doesn't really help here since it produces parsing
errors in downlevel clients and has to live in separate <script>s.
It's much more likely that we'd see code like:

var value = obj.get(name)[0];

>>> I'll leave out set() for now.
>> This also seems like optimizing for the rare case.
> What semantics would you propose?

replace the first instance with the new value. Remove all other
instances. Append if no instance exists. We'd definitely still need to
keep the .append() function though.

I can live with names other than 'set' if that is the controversial
bit. I don't understand why there's all this resistance to creating an
API which is compatible with existing JS APIs though? The DOM going
its own way and using a "not invented here" approach has always seemed
like a bad thing to me.

As far as I can tell it should be possible to make this object fully
compatible with a Map.

/ Jonas
Received on Monday, 9 September 2013 22:32:15 UTC

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