. Zakas
Twitter: @slicknet
Blog: http://www.nczonline.net/
*From:* Peter van der Zee qfo...@gmail.com
*Sent:* Thursday, January 13, 2011 8:43 AM
*To:* jsmentors@googlegroups.com
*Subject:* Re: [JSMentors] JS API Design - Accepting Parameters
On Thu, Jan 13, 2011 at 5:37 PM, Arlo arlo.carr
I am developing a JS API for my employer and I constantly ask myself
how I should accept params into my methods. So I figured I would ask
the professionals.
Here is my scenario:
1.) I know a handful of basic methods that I need to implement right
now.
2.) I do not know if functionality in these
On Thu, Jan 13, 2011 at 5:37 PM, Arlo arlo.carr...@gmail.com wrote:
Example Method:
A.) function drawPolygon( points, polyOptions ) { ... }
B.) function drawPolygon( options ) { ... }
I feel that with option B I can expand functionality a lot easier than
with option A. Does anyone have
What I do is:
1. If I'm quite sure there will be only 1: foo(arg)
2. If I'm quite sure there will be only 2: foo(arg1, arg2)
2. If I'm quite sure there will be more than 2: foo(/*Object*/args)
3. if I'm not sure how many of them there will be in the future:
foo(/*Object*/args)
4. if I'm quite
Support both.
If you are hesitant, you can support both ways. Take the jQuery API
for example. It supports optional arguments, and depending on the type
of the arguments they behave differently.
--
Poetro
--
To view archived discussions from the original JSMentors Mailman list:
On 13 January 2011 18:26, Poetro poe...@gmail.com wrote:
Support both.
I was going to say exactly the same thing. If you only need two arguments at
the moment, use two arguments. If you need to expand later, make it so the
function can optionally take a single options object. This doesn't have
Hi
Let's say you go for B), there's a good pattern you can use explained here:
http://enterprisejquery.com/2010/08/javascript-parameter-patterns-with-extend-and-beyond/
I personally go for option B) when I cannot remember the order of the arguments
or there simply are too many ( 3).
Cheers
tj
When creating an API, I always try to be as friendly as possible to
the 'user' (the programmer using that API). So usually the best option
is to support as many type of arguments (object, separate values...)
as you can. Also, try to be permissive with the order. For example, if
you build a join()
On Thu, Jan 13, 2011 at 9:37 AM, Arlo arlo.carr...@gmail.com wrote:
Here is my scenario:
1.) I know a handful of basic methods that I need to implement right
now.
2.) I do not know if functionality in these methods will expand in the
future
Example Method:
A.) function drawPolygon(
