TypedJS: Sanity Check your JavaScript | Hacker News Reader

TypedJS: Sanity Check your JavaScript

typedjs.com

68 pointsunignorant20 comments

Please don't use non-commercial licences: you are greatly limiting the number of people who can afford to contribute to your project.

Furthermore I don't think CC licenses are meant to be used for code: http://creativecommons.org/software

Interesting, but if I wanted to get this sort of validation I'd just use Google's Closure Compiler. It supports validating types and also lets you do things like casting variables to different types. And the annotation method is pretty clear, flexible, and easy to understand.

Can the implementation be typed? https://github.com/Proxino/TypedJS/blob/master/typed.js

At first glance this is a fuzz generator not a type checker.

What is the license that is free for non-commercial use? Static type checking is nice but implementation in a non-statically-type-checked language is unfortunate.

I think Closure Compiler is a lot more useful than this. You get type checking, but you also get best of breed optimization/minification too.

You don't get the automatic runtime test generation stuff, but that's more along the lines of an add-on utility like Quickcheck/Scalacheck.

The add_all() function as presented on their web page is wrong,instead of adding the array elements it just returns the last one.

Line 180 should be: count += num_arr[i];

Moreover naming accumulation variable for sum "count" is totally counter intuitive.

Interesting idea but I'd hate to maintain that.

How much performance hit would it costs, and is there a companion tool that I can remove only those comments with types?

I never saw someone using "nil" in JavaScript (even in a comment). I guess the author has a Ruby background.

From their home page example

if(obj.valid === true) {

I would flag this line as an error.

Why? obj is specified by the type annotation to be an object with a property 'valid' that is a Boolean, so what's the problem?

I just don't like this style very much. It's better to write

if (obj.valid) {

Sure, I agree it is poor style. I guess I assumed because of the context you were saying you would expect the type checker to flag it as an error.

Sometimes, and I mean just sometimes, it is better to just use ===. For instance, I recently wrote some code where a variable has a value of type Number, but I use "false" to signal the absence of such value (in the sense that the value is not available yet). In that case, I have to use stuff like if(x !== false), because "0" is a valid value in that context.

`if (foo)` and `if (foo === true)` aren't equivalent.

According to the TypedJS annotation for the function they are. The function definition says that obj.valid has to be a boolean, so any other type of falsy input (0, undefined, null, etc) should never be provided as an argument here.

While uglier === is much more specific and enforces types... Which seems germane here.

It would be more interesting if you could also use the annotations to type-check at runtime (optionally). That way if the annotations diverged from the actual code, you'd find out.

Reply on news.ycombinator.com