- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 22 Aug 2014 11:26:52 +0200
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: James Graham <james@hoppipolla.co.uk>, WHATWG <whatwg@lists.whatwg.org>, Alex Russell <slightlyoff@google.com>
On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald <jaffathecake@gmail.com> wrote: > On 22 August 2014 07:20, Anne van Kesteren <annevk@annevk.nl> wrote: >> That works for me too. I agree that developers will likely learn what >> is going on here quickly enough. And that if anything should have long >> names, it would be some new API that would use more memory. Jake? > > Reading a url as some format is really common, so I'm in favour of shorter > method names. > > var data = await (await fetch('/whatever')).asJSON(); > > The consuming behaviour may catch some developers out, once, in their > development environment. > > I don't think Alex & Domenic were as keen & wanted something in the name to > represent consuming/taking. James pointed out on IRC we could simply have this: response.json() response.text() request.formData() I did not like this at first. However, if we care about brevity, and we often said we do and act in that manner (see e.g. querySelector -> query), he is right. "as" does not really add anything. "bodyAsJSON" is a bit more descriptive and "takeBodyAsJSON" is even more, but in the end everyone will know very quickly that response/request can only have their body read once and will dislike us for having to type those extra characters (and will then type another couple to complain about it on Twitter). I checked and none of the existing properties clash with data types we might want to add in the future. I think those, combined with exposing state through hasBody should be the way forward. -- http://annevankesteren.nl/
Received on Friday, 22 August 2014 09:27:16 UTC