W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier

From: Jake Archibald <jaffathecake@gmail.com>
Date: Fri, 22 Aug 2014 09:32:14 +0100
Message-ID: <CAJ5xic_5tt7Ufgev3nBto5AcWjEqaz2xu6pptcZOkkvGtpWFnQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: James Graham <james@hoppipolla.co.uk>, WHATWG <whatwg@lists.whatwg.org>, Alex Russell <slightlyoff@google.com>
On 22 August 2014 07:20, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Aug 22, 2014 at 12:27 AM, James Graham <james@hoppipolla.co.uk>
> wrote:
> > I think that adding an extra verb to the names to describe a consistent
> > feature of the API is a mistake; it seems important when designing the
> > API because it's a choice that you have to make, but for the user it's
> > just part of how the API works and not something that needs to be
> > reemphasized in the name of every piece of API surface. For example
> > given a language with immutable strings it would be pure noise to call a
> > method "appendAsNewString" compared to just "append" because all
> > "mutation" methods would consistently create new strings.
> So you argue for asX()? Perhaps bodyAsX() to make it clear what field
> of request/response we're talking about. And then hasBody as property
> or some such?
> 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.
Received on Friday, 22 August 2014 08:32:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC