Tuesday, April 7th, 2009

Chrome Extension API; How we wish we have named parameters

Category: Chrome, JavaScript

pre>

This is how you will probably create a new tab using the Chrome extensions API when it comes out.

Aaron Boodman talked about the choice and how they are looking to make the APIs look more like this:

I’m using the CRUD pattern as a starting point for all the major sub-systems’ APIs. My hope is that this will have a number of positive effects:

  • Minimize API design hand-wringing
  • Provide a large base of functionality quickly
  • Make it easy for Chromium developers to add new APIs
  • Make it easy for extension developers to learn new APIs

I got this all working for a few methods, and then I got to writing the validation code. I could write the code by hand, but that’s so much work. And why bother when somebody has gone and invented JSON Schema.

That’s right, it’s a schema language for JSON. And of course it has a schema, written in JSON schema. Whee!

So we should be able to just declare the expected structure for our API parameters and push the validate() button. Probably there will have to be extra stuff around the edges, but this should get rid of a majority of the grunt work.

I have found that I favor this approach a lot, and you see the same in libraries such as Prototype (Ruby does a lot of this hash munging too). I wish we could just get named parameters in the language so this all just integrated very nicely indeed. What do you think?

Related Content:

Posted by Dion Almaer at 6:13 am
7 Comments

+++--
3.5 rating from 21 votes

7 Comments »

Comments feed TrackBack URI

Named parameters have come up on es-discuss from time to time, I expect we’ll see them in the not so distant future.

Comment by TNO — April 7, 2009

It was something we found we needed in json-rpc to make life easier. It makes more sense if you think of api methods as properties that take an array or an object, especially when you go into doing work at language agnostic levels.

Comment by mpcm — April 7, 2009

I would hope that the “selected” property was named “hasFocus” instead due to selected having multile meanings such as when you tab to an object.

Comment by EliGrey — April 7, 2009

+1 for named params, ala Python. In some sense we already have them, but not in the “optinal in any order property bag” syntax.

Comment by slightlyoff — April 7, 2009

I would hope that the “selected” property was named “hasFocus” instead due to selected having multile meanings such as when you tab to an object.

“Focus” suffers from the same problem. “Selected” is more accurate, at the least, and really who cares? It’s not like developers are going to utterly confuse the tab system with a webpage checkbox.

Comment by eyelidlessness — April 7, 2009

Ruby has shown us that a bit of syntactic flexibility can go a long way. For instance, Ruby has “getters” and “setters” simply because parentheses are optional in method calls.

Likewise, one can leave off the braces when passing a hash into a method (except where it would cause ambiguity), thus approximating named parameters. If we could likewise leave off the braces in JavaScript, we’d be 90% there.

Comment by savetheclocktower — April 8, 2009

Explain again why removing the { & } characters is a good idea. Just pretend you have a cute little pinchy crab hugging all your properties ^_^

Comment by SubtleGradient — April 9, 2009

Leave a comment

You must be logged in to post a comment.