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...


seems to at least give the hint that it is a stream that is consumed
without getting too crazy.

Brian Kardell :: @briankardell :: hitchjs.com

Reply via email to