4 ms·

It's an optional mode via command line, no? Opt-in won't require anyone to use closure.

by fortes 15y ago

jashkenas 15y ago
Fair enough ... it's definitely worth considering seriously. I'd probably wait until it's "finished" according to Michael, and then look at if it's possible to add enough hooks to the compiler for it to be implemented as a plugin. Ideally you'd be able to emit different annotations depending on your use case, for example: lots of other folks have requested automatic JSDoc annotations.
- fortes 15y ago
  Love it. Could also imagine an ES5 mode, etc.
- withjive 15y ago
  What's the chance of also getting optional Type Annotations into CoffeScript core as well? As this would greatly help the closure compiler do optimisations, and since it is opt-in to add the typed parameter and would only produce a javascript comment above said variable. For example.... foo <: String = "hey" /* @type {String} */ var foo = "hey" I don't think this is deviating from CoffeeScript's aim to keep things pure? Is it?
  - jashkenas 15y ago
    It is deviating pretty far from compiling to readable, standard JS, but again ... as a fork or a plugin, I'm all for it. The reason why the entire CoffeeScript source is annotated is to make variants like this easier to accomplish. That said, statically marking your variables with "types" (where types are incredibly weak and limited in JavaScript) isn't going to be of much use to you, performance-wise. Modern engines like V8 already unbox local variables where possible, and do "hidden class" analysis to give a "type" even to regular unstructured JS objects.
    - withjive 15y ago
      What I'm after for typed annotations is integration with the closure compiler to give me static checking, so in large codebases I get that type safety, even in javascript. Thanks anyways though
    - noonat 15y ago
      A standard way of doing type annotations would also make it possible to generate AS3 code with CoffeeScript.

It's an optional mode via command line, no? Opt-in won't require anyone to use closure.

by fortes 15y ago

It's an optional mode via command line, no? Opt-in won't require anyone to use closure.

Fair enough ... it's definitely worth considering seriously. I'd probably wait until it's "finished" according to Michael, and then look at if it's possible to add enough hooks to the compiler for it to be implemented as a plugin. Ideally you'd be able to emit different annotations depending on your use case, for example: lots of other folks have requested automatic JSDoc annotations.

fortes 15y ago
Love it. Could also imagine an ES5 mode, etc.
withjive 15y ago
What's the chance of also getting optional Type Annotations into CoffeScript core as well? As this would greatly help the closure compiler do optimisations, and since it is opt-in to add the typed parameter and would only produce a javascript comment above said variable. For example.... foo <: String = "hey" /* @type {String} */ var foo = "hey" I don't think this is deviating from CoffeeScript's aim to keep things pure? Is it?
- jashkenas 15y ago
  It is deviating pretty far from compiling to readable, standard JS, but again ... as a fork or a plugin, I'm all for it. The reason why the entire CoffeeScript source is annotated is to make variants like this easier to accomplish. That said, statically marking your variables with "types" (where types are incredibly weak and limited in JavaScript) isn't going to be of much use to you, performance-wise. Modern engines like V8 already unbox local variables where possible, and do "hidden class" analysis to give a "type" even to regular unstructured JS objects.
  - withjive 15y ago
    What I'm after for typed annotations is integration with the closure compiler to give me static checking, so in large codebases I get that type safety, even in javascript. Thanks anyways though
  - noonat 15y ago
    A standard way of doing type annotations would also make it possible to generate AS3 code with CoffeeScript.