On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell <bkard...@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

> 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

> --
> http://annevankesteren.nl/

Brian Kardell :: @briankardell :: hitchjs.com

Reply via email to