- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 10 Sep 2013 02:39:17 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Tue, Sep 10, 2013 at 1:15 AM, 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. I don't really think there's a mismatch. A consumer can either operate on the data as simple name/value map. In which case he/she would use the obj.get and obj.delete functions. Or the consumer that wants can support multiple values for each name, in which case he/she would use obj.getAll/obj.delete. In either case the function pairs expose consistent behavior. By allowing consumers to treat the query data as a simple map we actually reduce the risk of bugs due to multiple values being passed to a page that didn't expect it. Instead additional values are ignored. However consumers that does want to support multiple values get a perfectly consistent and sensible API for handling that. Same thing if we add .set to the mix. get/delete/set create a consistent API which as a bonus reuses the same API as Map. Likewise getAll/delete/set/append expose a consistent API for handling multiple values. I agree that it's not a perfect API for handling multi-values since it doesn't support things like "replace the second value" or "delete the second value". However that can be added later if really needed. I'd tend to guess that the use cases are rare enough that it's fine to leave out. >> 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. > > I don't understand what you mean here. We have gotten a lot of critisism over the years for creating APIs that doesn't reuse existing JS infrastructure. And rightfully so. It's annoying for authors to have to learn a new variations of interacting with the APIs that they are using. >> 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. For consumers that want simple name/value mappings it is fully compatible with Map. As an added bonus it is compatible with Map even when passed multiple values for a single name. For consumers that want to deal with multiple values it is of course impossible to make it compatible with Map. / Jonas
Received on Tuesday, 10 September 2013 00:40:15 UTC