gistfile1.coffee

# So, I have some class defintiions
# written in coffeescript.  I am writing
# an app in coffeescript, which reads these files
# on disk.  I have access to the coffeescript compiler
# from inside of my app.

class SomeClass
  doSomething: ()->
    1 + 1 = 2
#
# I want to be able to read the contents of
# this file on disk, and then request the body of any
# method definition by name.
#
# in the coffeescript REPL, SomeClass.doSomething.toString()
# returns the compiled javascript, which is expected. but what
# I want is to be able to get the method definition as it was
# written in coffeescript.
#
# I am able to just parse the file, find the line where a method
# is defined, and then work off of indentation, but this doesn't
# feel correct to me.

Parse the CoffeeScript, get an AST, walk the tree, find your methods, write a tiny little code generator that takes a coffee AST and outputs coffeescript code, map it over the methods you found earlier.

Thanks Michael, I figured it was something along these lines. We would still lose some stuff in translation this way. Probably not a big deal

…

On May 26, 2012, at 8:41 AM, Michael ***@***.*** wrote: ## Parse the CoffeeScript, get an AST, walk the tree, find your methods, write a tiny little code generator that takes a coffee AST and outputs coffeescript code, map it over the methods you found earlier. Reply to this email directly or view it on GitHub: https://gist.github.com/2792913

Nothing should be lost. I don't see why it would. Only concrete syntax (and comments), but you can design your rules to format the output however it is preferred.

I think things like 'and' and '&&' might not get picked up exactly like they're written,but you're correct that I can control that for my own rules Let me ask this, would working off indentation and just parsing the text naturally be a bad approach? Can you think of any cases where it would not work? The fact that I will be parsing backbone components only with this tool limits the range of possible inputs Thanks

…

On May 26, 2012, at 7:49 PM, Michael ***@***.*** wrote: ## Nothing should be lost. I don't see why it would. Only concrete syntax (and comments), but you can design your rules to format the output however it is preferred. Reply to this email directly or view it on GitHub: https://gist.github.com/2792913

I would take advantage of the CoffeeScript compiler's built-in parser. You're setting yourself up for failure if you try to do naive string matching. Do it the right way the first time and you'll end up saving yourself time in the long run. It's not even very difficult.

Agreed but I am trying to build an editor environment so losing minor syntax style in translation is potentially a bad deal. it only effects things like and, or, is, isnt though. I was able to use function.toString() and js2coffee in a browser, which you can imagine was much worse, so by comparison this still is a welcome option

…

On May 26, 2012, at 8:39 PM, Michael ***@***.*** wrote: I would take advantage of the CoffeeScript compiler's built-in parser. You're setting yourself up for failure if you try to do naive string matching. Do it the right way the first time and you'll end up saving yourself time in the long run. It's not even very difficult. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2792913

You're also going to introduce (inconsequential) whitespace differences. What you really need is an AST that preserves the concrete syntax that caused the parser to create it. For that, you're either going to have to wait for my kickstarter to be done or fork CS and do it yourself.