On Fri, Aug 22, 2014 at 5:26 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald <jaffathec...@gmail.com> > wrote: >> On 22 August 2014 07:20, Anne van Kesteren <ann...@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/
I still think that calling it bodyStream actually helps understanding all you need and it's short/portable... response.bodyStream.asJSON() seems to at least give the hint that it is a stream that is consumed without getting too crazy. -- Brian Kardell :: @briankardell :: hitchjs.com