jlongster/nunjucks — pull request #8 by bhagany (2012-09-28 21:43:02+00:00)
Title: Macro definition and calling

A few things you probably want to take a look at:

- I created a wrapMacro function in the runtime module, to facilitate translating between nunjucks' keyword arguments, and javascript, which has none. It's the equivalent of jinja2.runtime.Macro
- In order to access wrapMacro at render time, I needed an equivalent to the imports that jinja2 does at the top of its generated code. I ended up just passing the runtime module as an argument to rootRenderFunc. It seems straightforward enough to me, but I'm open to better ways.
- To account for keyword/default arguments, I ended up creating a new Argument node, which get added as children to FunCall
- Because of the Argument nodes, and the need to call macros differently than js functions, I heavily modified compileFunCall. It now generates a ternary that calls the function differently based on the isMacro property I attach to macro functions. This is the bit I'm the least happy with, there's a fair amount of repetition in compileFunCall, and I find it difficult to read. I figured I'd let you sign off on the general approach before I spent time cleaning it up.
- You'll also see some repetition in parseSignature and parseCallSignature, both of which are new in this commit. Same thought process as above.

And some trivial things:

- There are some line changes that just remove trailing whitespace. Sorry about cluttering the diff, I have my editor configured to automatically do that.
- I rebuilt the browser files; I'm pretty sure I did it correctly, but you may want to double check
- I started implementing the special jinja macro magic, like varargs and extra kwargs, but decided that this was overkill for a first pass. You can still see some remnants of this, for example, in extra arguments to wrapMacro.

I think that's about it; I'd be happy to hear what you think.