- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Fri, 22 Aug 2014 09:32:14 +0100
- 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