On 22 August 2014 07:20, Anne van Kesteren <ann...@annevk.nl> wrote: > On Fri, Aug 22, 2014 at 12:27 AM, James Graham <ja...@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.