- From: Brian Kardell <bkardell@gmail.com>
- Date: Fri, 22 Aug 2014 14:29:50 -0400
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: James Graham <james@hoppipolla.co.uk>, WHATWG <whatwg@lists.whatwg.org>, Alex Russell <slightlyoff@google.com>, Jake Archibald <jaffathecake@gmail.com>
On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell <bkardell@gmail.com> wrote: >> 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. > > Well 1), > > response.json() > > is short too, much shorter in fact. > It is, but there was concern that is was too short to be clear/might actually be confusing before it was further shortened. Making it shorter doesn't help that objection - it doesn't make it clearer, does it? I'm not saying "this is best" I'm offering a proposal that tries to strike the balance with this fact - that's all there is to my comment. > 2) We have no idea what the design of what bodyStream's getter returns > is or should be. There was a body property, I merely proposed renaming it to bodyStream. If you're saying that we've definitely decided to not directly expose the stream, merely means of consuming because of the open question of what streams look like, then yes, that's a good argument against what I'm saying... I might have missed that that decision was made, was it? > 3) As already indicated, after you use this once, you realize how it works. Yes and no... It's moderately easier to learn if the API is clearer about what is is, and it's definitely easier to recognize in code without searching for context when 'response' could be several things. It's all a balancing act of cost and benefit (see next comment) > 4) I don't see how yours is more portable than James' proposal. I didn't say it was, I just said it -was- portable... You could imagine carrying the lesson that stream based properties identify themselves as such across the platform - it's not overly long and they would be easily recognizable - maybe that's a good balance, maybe it's not.... You could definitely make the same argument with .json(), though it's different in the sense that there is no hint as to what you can .json() and what you can't. I'm definitely not saying "bodyStream or it's wrong", but the API when I suggested it as an option at least was discussing methods like response.body.consumeAsJSON which is longer, less clear to me and offers no kind of hints or portability of the idea that I can really see. > > > -- > http://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
Received on Friday, 22 August 2014 18:30:39 UTC