[phase_9]

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]

Why using :

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

Over :

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

Coercion avoidance ?

[dagw]

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

[niyazpk]

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.

[1wheel]

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

[elclanrs]

I'd use:

  bar = bar != null ? bar : 'default';

[ifuller1]

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?

[adam-a]

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.