21–30 of 282 posts
Is the type syntax friendly with CoffeeScript?
You can probably hack it using the backtick operator though.
`function foo(x: string, y: number): string {`
x.length * y
`}`What mechanism ensures this becomes valid javascript? does the code need to be compiled?
Is the type syntax friendly with CoffeeScript?
It'd be quite possible to add the ability to output these annotations to the CoffeeScript compiler itself though. Could be an interesting fork.
Question, in the doc it shows a code snipped that has the functioned defined as such "function foo(x: string)" What mechanism ensures this becomes valid javascript? does the code need to be compiled?
http://flowtype.org/docs/existing.html#_ http://flowtype.org/docs/running.html#_
From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org
function length(x) {
return x.length;
}
length(null);
Question, in the doc it shows a code snipped that has the functioned defined as such "function foo(x: string)" What mechanism ensures this becomes valid javascript? does the code need to be compiled?
Question, in the doc it shows a code snipped that has the functioned defined as such "function foo(x: string)" What mechanism ensures this becomes valid javascript? does the code need to be compiled?
The code has a build step - yes. You will not be able to run this code without a step. It could be awesome if they allowed annotations in comments like other tools do - there is a GH issue on that and it looks like it should be possible https://github.com/facebook/flow/blob/master/src/typing/comm...
From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org
TS bolts on a straightforward nominative type system without type unions (or non-nullable types), so it can't handle a variable typed as `number | string`, it'll immediately drop down to `any`. That is, flow aims to remain useful in the face of more JS idioms. It won't make a difference between nullable and non-nullable either, so AFAIK function length(x) { return x.length; } length(null); can never be a compile-time…
Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I'm sure static type checking can benefit some organizations,…
Then again their rationale is very clear and pretty good: You need builds if you're using Facebook's stack anyway (for JSX) so this should not interfere with your current build - which you have to do anyway.
How this compares to TypeScript? At the quick glance I noted: - more powerful type system (union types, hurray) - support for JSX - no windows binaries - supports more of ES6 stuff - ...but has no support for modules yet - no generics (??) How about performance? and workflow? Didn't yet find this: does it use a normal "write then compile" model like TS or has something like Hack (if I'm not mistaken it has a daemon r…
I see some mentions of import in the tests and the grammar: https://github.com/facebook/flow/search?utf8=%E2%9C%93&q=imp...