- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 10 Sep 2013 15:22:16 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Tue, Sep 10, 2013 at 2:50 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Tue, Sep 10, 2013 at 10:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> Some of the developers who have been vocal about bad API design >> support the changes I suggested (and Rick actually suggested them to >> me a while back, which I forgot about :/), so I'm not sure what you >> say here captures their concerns accurately. > > Also, we shouldn't be doing API design based on who-said-what but > rather than on technical arguments. We've always been doing that, no? Still got us that critique. > My arguments are > > * We should make the DOM more similar to ES since it is less API > surface for users to use. Agreed. Note that this argument does not imply we should try to shoehorn a data type that's different into a Map. It means we should understand how the design applied to Map and other features of JavaScript, would apply to something like URLQuery and FormData. > * It enables authors to treat the map as a simple name/value map and > get a consistent API that exposes that. I hope the emails from Tab and > I explain how the API is consistent. I think Tab's email about the dual API on top of one data type makes sense, but note that there's no precedent for that in JavaScript (though I suppose down the road promises may become one). From what I can tell the way JavaScript is being designed today it would not have these kind of shortcut mechanisms, which I think is why Rick's and Domenic's input is important since they've been more closely involved in that process. I'd be interested in hearing what they have to say though. -- http://annevankesteren.nl/
Received on Tuesday, 10 September 2013 14:22:44 UTC