Skip to content

Compiler directives #468

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
TrevorBurnham opened this issue Jul 2, 2010 · 7 comments
Closed

Compiler directives #468

TrevorBurnham opened this issue Jul 2, 2010 · 7 comments

Comments

@TrevorBurnham
Copy link
Collaborator

In large projects I inevitably wind up with some files where it would be nice to compile them with --no-wrap. Now that #-style comments are omitted from JavaScript output, perhaps it would make sense to use a syntax along the lines of

# flags: no-wrap

for such directives. Or maybe the syntax should be more clearly differentiated from comments aimed at humans, e.g. starting with #!.

I would allow this after human-readable comments, but before any expressions. There may be other directives in the future (perhaps a way of including another file, or a flag that adds comments to the output with the line numbers of the original CoffeeScript), but this is the only one that I feel a real need for, and it should be fairly easy to implement (I'd be happy to write the patch myself if there's support for it). Thoughts?

@jashkenas
Copy link
Owner

When do you not want the wrapper, in a large project? Don't you prefer to attach your public objects to a namespace of some sort, or failing that, window?

@TrevorBurnham
Copy link
Collaborator Author

Normally, yes—which is why I wouldn't want to run the compiler with --no-wrap on the whole project. But if I have something like, say, a file full of utility functions, so the file is just a series of

window.doSomething: -> ...

statements, then the wrapper feels a bit wasteful. It's mainly an aesthetic thing, though if one were trying to squeeze the minimum number of bytes out of the minifier, it would help with that too.

@bnolan
Copy link

bnolan commented Jul 4, 2010

Trevor - you can copy all your items from the current scope into a namespace using something like:

for key, value in this
  window[key]: value

I vote for keeping coffeescript simple, no flags! It may cause issues with multiple coding styles in large projects, or with the different envs .cs runs in (eg the <script type="text/coffeescript"> tags).

@jashkenas
Copy link
Owner

Amen to that. Let's keep it simple. If you want to have special per-file configuration, then that sounds like something that would be good to script out -- or to add to your Jitter project. Closing as a wontfix.

@redexp
Copy link

redexp commented Jan 8, 2013

Hey all, I also thought about directives like in C and I think it would be helpful in coffee. For example #ifdef #else #endif will help to build development and production files like

getItem = (index) ->
  #if DEBUG_MODE
  if index < -1
    throw new Error('List::getItem - index out of range')
  #endif
  this.list[index]

so if I set #define DEBUG_MODE 1 then code will be compiled to

getItem = function(index) {
  if (index < -1) {
    throw new Error('List::getItem - index out of range');
  }
  return this.list[index];
};

and if #define DEBUG_MODE 0 then

getItem = function(index) {
  return this.list[index];
};

on production code should be small and fast. Also in debug version can be not only exceptions, but some functions which will add some statistics or other stuff. Really helpful

And maybe also add one more parameter to coffee compiler like -d to pass constants like this

coffee -c script.coffee -d DEBUG=1

@vendethiel
Copy link
Collaborator

What a bump ! You should probably create another issue, since your suggestion is a bit different

@GeoffreyBooth
Copy link
Collaborator

Line comments are now output, via #4572. So comment-based directives should now be possible.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants