4 ms·

Wouldn't sweet.js and a macro make a more eye appealing solution? The idea is nice and all but the syntax... is just so ugly.

acjohnson55 13y ago
I was thinking the same thing. That and I'm not understanding from the page how this is used in the first place. Is the `arguments` implicit variable being passed in some place? (EDIT: yes, via `Function.caller`.) Are the argument values accessed through the result of calling `Args`? For a non-macro implementation of this, it might be interesting to use function decorator syntax instead, to put the argument processing outside the function body entirely. Basically, the argument processor decorator function would take an options array and a target function, which has all possible parameters, explicitly named. The decorator would spit out a new function that invisibly does all of the wrangling of `arguments` and then finally calls the target function. An advantage is that I think this would be the most minimal pure JS solution from a syntax perspective, and it would keep the actual function body uncluttered. A disadvantage is that it could only really be used with function expressions (not declarations).
- adam-a 13y ago
  I'm really excited about sweet.js and JS macros in general, but I haven't had a chance to dive into anything yet. The major disadvantage for me though is it adds a pre-processing step.
  - Touche 13y ago
    Not necessarily, sweet.js runs in the browser and there is a plugin for Requirejs so it can be transparent to you during development.
  - acjohnson55 13y ago
    I think resistance to pre-processing is futile. Most people already use it for minification at the very least. With things like brunch and grunt, pre-processing can be pretty much transparent during development. I actually don't know what sweet.js's sourcemap story is, but potentially transparency could more or less be achieved even during debugging. Maybe we'll eventually even get native JS macro language support!
brandonbloom 13y ago
More than that, macros would be a static solution, expanding to sensible arguments parsing code at compile time. So much metaprogramming these days is dynamic where you pay excessive interpretive cost to evaluate the little DSL every time the function is called. JavaScript programmers are guilty of this, but not nearly as guilty as Ruby programmers...

acjohnson55 13y ago

I was thinking the same thing. That and I'm not understanding from the page how this is used in the first place. Is the `arguments` implicit variable being passed in some place? (EDIT: yes, via `Function.caller`.) Are the argument values accessed through the result of calling `Args`? For a non-macro implementation of this, it might be interesting to use function decorator syntax instead, to put the argument processing outside the function body entirely. Basically, the argument processor decorator function would take an options array and a target function, which has all possible parameters, explicitly named. The decorator would spit out a new function that invisibly does all of the wrangling of `arguments` and then finally calls the target function. An advantage is that I think this would be the most minimal pure JS solution from a syntax perspective, and it would keep the actual function body uncluttered. A disadvantage is that it could only really be used with function expressions (not declarations).

adam-a 13y ago
I'm really excited about sweet.js and JS macros in general, but I haven't had a chance to dive into anything yet. The major disadvantage for me though is it adds a pre-processing step.
- Touche 13y ago
  Not necessarily, sweet.js runs in the browser and there is a plugin for Requirejs so it can be transparent to you during development.
- acjohnson55 13y ago
  I think resistance to pre-processing is futile. Most people already use it for minification at the very least. With things like brunch and grunt, pre-processing can be pretty much transparent during development. I actually don't know what sweet.js's sourcemap story is, but potentially transparency could more or less be achieved even during debugging. Maybe we'll eventually even get native JS macro language support!

brandonbloom 13y ago

More than that, macros would be a static solution, expanding to sensible arguments parsing code at compile time. So much metaprogramming these days is dynamic where you pay excessive interpretive cost to evaluate the little DSL every time the function is called. JavaScript programmers are guilty of this, but not nearly as guilty as Ruby programmers...