Args.js – Optional and Default parameters for JavaScript

http://autographer.github.io/args.js/

by adam-a • 13 years ago

53 39 13 years ago

autographer.github.io

gosukiwi• 13 years ago

Wouldn't sweet.js and a macro make a more eye appealing solution? The idea is nice and all but the syntax... is just so ugly.

acjohnson552• 13 years ago

I was thinking the same thing.

That and I'm not understanding from the page how this is used in the first place. Is the `arguments` implicit variable being passed in some place? (EDIT: yes, via `Function.caller`.) Are the argument values accessed through the result of calling `Args`?

For a non-macro implementation of this, it might be interesting to use function decorator syntax instead, to put the argument processing outside the function body entirely. Basically, the argument processor decorator function would take an options array and a target function, which has all possible parameters, explicitly named. The decorator would spit out a new function that invisibly does all of the wrangling of `arguments` and then finally calls the target function. An advantage is that I think this would be the most minimal pure JS solution from a syntax perspective, and it would keep the actual function body uncluttered. A disadvantage is that it could only really be used with function expressions (not declarations).

adam-a7• 13 years ago

I'm really excited about sweet.js and JS macros in general, but I haven't had a chance to dive into anything yet. The major disadvantage for me though is it adds a pre-processing step.

brandonbloom• 13 years ago

More than that, macros would be a static solution, expanding to sensible arguments parsing code at compile time. So much metaprogramming these days is dynamic where you pay excessive interpretive cost to evaluate the little DSL every time the function is called. JavaScript programmers are guilty of this, but not nearly as guilty as Ruby programmers...

nebulous1• 13 years ago

Appears to use Function.caller ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... )

"Non-standard This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future."

mmastrac• 13 years ago

It might not be on the standards track, but the browser support table at the bottom seems to indicate that this is a de-facto standard.

gnud• 13 years ago

It seems like you can avoid using Function.caller by suppling Args.js with the arguments yourself, like

Args([/* argument definition */], arguments);

adam-a7• 13 years ago

That's right. The Function.caller bit was only added in quite late and the library works just as well without it, although you have to type a bit more.

phase_9• 13 years ago

I've seen this style of library come up quite a few times whilst hacking away in JavaScript where developers try to introduce a sense of strict typing (I even wrote a similar one myself when I first moved over from ActionScript). In the end I learned to stop worrying and love the <strike>bomb</strike> duck typing[0].

For me; one of the "joys" of coding JavaScript is the expressiveness that comes with a dynamic languages; should you throw an ArgumentError when your function that expects a number is invoked with a String? Maybe - sure it can help catch problems early and effectively "stop-the-line" in your public API, but then again it will probably end up throwing the classic `TypeError: Object foo has no method 'bar'` for you anyway.

For "public" methods which form part of an API (especially when that API is going to be shared outside of my team) I try to make my functions handle failure early (before they delegate off to the "private" internal methods), even better if the public methods can repair any unexpected usage, ie:

  function convertToHex(value) {
    var result;
    
    if (typeof value !== "number") {
      result = convertToHex(parseInt(value, 10));
    }
    else {
      result = "0x" + value.toString(16);
    }
    
    return result;
  }

Also, with regards to default argument values, I've always felt the "native" JavaScript approach was fairly compact and descriptive when required:

  function doFoo(bar) {
    bar = (bar !== undefined) ? bar : "default_value";
  }

[0] http://en.wikipedia.org/wiki/Duck_typing

simon_renoult• 13 years ago

Why using :

    function doFoo(bar) {
      bar = (bar !== undefined) ? bar : "default_value";
    }

Over :

    function doFoo(bar) {
      bar = bar || "default_value";
    }

Coercion avoidance ?

1wheel• 13 years ago

0 is falsy in javascript; with the second method, default_value will get used instead.

niyazpk• 13 years ago

Yes, the second option is better in most cases. I'd spend more time reading the first one to understand what is going on compared to the second option.

Keep in mind that you will have to go for the first option (or other better options) if you expect 'falsy' values to be passed as arguments.

dagw• 13 years ago

The second function sets bar to "default_value" if called with a falsy argument like 0 or an empty string.

adam-a7• 13 years ago

For me it was partly about providing type errors, but also very much about providing easy to write and easy to read type testing and sorting. Type testing in javascript can be a bit tough on the eye and this hopefully makes it easy to see what parameter types a function will accept.

ifuller1• 13 years ago

I'm not sure that embracing a languages dynamic nature should get in the way of leveraging libraries to write more readable code. One advantage of using a standard approach (be it a third party library, or something bespoke) is that you could enable / disable the 'type checking' depending on the build environment. I wouldn't be surprised if your existing toolchain isn't already bringing some static inference to your development - are you using jsdoc and an IDE with autocomplete, for example?

Trusting you find Dart, Typescript, et al agreeable you have to concede that some people are working with legacy code and can only make iterative changes to their codebase?

callum852• 13 years ago

Big caveat: this doesn't work in strict mode.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Touche2• 13 years ago

Just comment out the line that uses caller and always pass your arguments.

adam-a7• 13 years ago

I was unaware of the strict mode problem. I never use it myself, probably because I'm not developing for the web, but a browser embedded in a desktop app.

I will have a look at providing a version that works in strict mode.

jdc0589• 13 years ago

Seen lots of these at this point. I still don't really understand their purpose.

Its not hard, and doesn't require much, if any, more code than the config options for libraries like this to just handle your arguments normally.

required arguments get defined in your function signature. You assign optional args to local variables defined within your function body via the arguments object. It's pretty easy.

adam-a7• 13 years ago

The original motivation was providing a single way to deal with a combination of default arguments, optional arguments and the sort of homebrew polymorphism that a lot of libraries use, where a function takes 4 different types of thing and runs through a bunch type tests before doing anything.

For functions with longer parameter lists this should hopefully be more readable too. It's clear what types can be passed to a function.

Out of interest, what other libraries like this have you seen? I did a quick check myself and couldn't find anything comparable.

ufo• 13 years ago

Another good reason to assign everything to a local variable ASAP is that if I leave everything in the args object then jshint can't help me prevent typos when accessing fields from that object.

curveship3• 13 years ago

'Args.caller.arguments' gives me the willies. That's a non-standardized extension combined with a deprecated one [0][1]. I'd have to be itching quite a lot to scratch it like this.

0 - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

1 - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

prezjordan• 13 years ago

Is there an alternative that provides the same functionality?

curveship3• 13 years ago

Not cleanly. You have to pass the arguments in explicitly, and you also need to convert them to an array (the arguments object is not an array [only array-like] and it's not supposed to escape its function body). So you need to do:

var args = Args([ ... defs ... ], Array.prototype.slice.call(arguments));

andrey-p• 13 years ago

I created something very similar recently, less features but more lightweight. Didn't plan to publicise it but I thought it's relevant:

https://github.com/andrey-p/arg-err

K0nserv2• 13 years ago

I experimented with something similar a while ago, however my main focus was strictness and not default and optional parameters. I did end up adding it though.

https://github.com/k0nserv/Strict.js

zephjc• 13 years ago

typo here in your readme:

    this.define('isFemale', female, String.Boolean);

should be

    this.define('isFemale', female, Strict.Boolean);

K0nserv2• 13 years ago

Will fix, thanks for pointing it out.

muskalek• 13 years ago

Or you can just use Coffeescript. http://coffeescript.org/#literals

Rygu• 13 years ago

You're missing the validation parts.

michaelwww• 13 years ago

TypeScript works for me and it doesn't require any additional JS code. Granted, it won't do runtime checks.

abimaelmartell• 13 years ago

nice idea but ugly sintax :S

Args.js – Optional and Default parameters for JavaScript

Related Stories