[nodejs] Getting a function object's argument names

[Drew Miller]

I need to get the argument names of a function object. I can do it by calling aFunc.toString() to get the source, and then parse the source to get the argument names, but before I go down that path, is there an easier way to do this?

To illustrate:

function funcThatGetsArgumentNames(func) {

 // this returns an array of the argument names of the passed function object; if I can't find a better way, I'll call .toString() (after validating it's a function object) and parse the source

}

var f = function(foo, bar, baz) {}

function funcThatNeedsArgumentName() {

  argNames = funcThatGetsArgumentNames(f)

  // argNames should now be [ "foo", "bar", "baz" ]

}

Thanks for the help,

Drew

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Kris Kowal]

On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
> I need to get the argument names of a function object. I can do it by
> calling aFunc.toString() to get the source, and then parse the source to get
> the argument names, but before I go down that path, is there an easier way
> to do this?

No. Also, bear in mind that JavaScript engines vary on how toSource a
function so doing this generally is even harder, and sometimes
impossible.

Kris Kowal

[Nicholas Campbell]

What are you attempting to do with this?

- Nick

On May 22, 2010 9:29 PM, "Kris Kowal" <kris....@cixar.com> wrote:

On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:

> I need to get the argum...

No.  Also, bear in mind that JavaScript engines vary on how toSource a
function so doing this generally is even harder, and sometimes
impossible.

Kris Kowal

--
You received this message because you are subscribed to the Google Groups "nodejs" group.

To po...

[Drew Miller]

Nick, this is for binding objects from various sources to HTTP request handlers based on what is "requested" by the handler via its arguments. I know there are various other ways to do this, many of them perfectly acceptable (I most often see other folks push stuff onto this with call); they're just not what I want. What I want is to support things like this:

webFx.handle("/a/static/path", function(request) { //... }

webFx.handle("a/route/with/:param, function(param) { // I don't need a request object }

webFx.handle("a/route/with/:param, function(param, request, user) { // I need the authenticated user }

webFx.handle("a/route/with/:param, function(session, param, user) { // I want session state, and order shouldn't matter }

webFx.handle("a/route/with/:param, function(session, param, user, someObjectIRegisteredViaDependyInjection) { // objects can come from many sources }

Again, I know of many ways to provide the means for what I want to do here, but this is the way I want my API. I already have a JavaScript parser written in JavaScript from another project, so parsing the source of the handler function is just fine. I was just curious if Node offered something special in this regard (I wasn't expecting it did).

Kris, this will only target Node; I'm not worried about differing toString() behavior on function objects in other engines.

Thanks,

Drew

[Kris Kowal]

On Sat, May 22, 2010 at 7:03 PM, Drew Miller <e...@anglicangeek.com> wrote:
> webFx.handle("/a/static/path", function(request) { //... }
> webFx.handle("a/route/with/:param, function(param) { // I don't need a
> request object }
> webFx.handle("a/route/with/:param, function(param, request, user) { // I
> need the authenticated user }
> webFx.handle("a/route/with/:param, function(session, param, user) { // I
> want session state, and order shouldn't matter }
> webFx.handle("a/route/with/:param, function(session, param, user,
> someObjectIRegisteredViaDependyInjection) { // objects can come from many
> sources }

If you're looking to have position independence and optionality, I
highly recommend having your handlers just accept an object with the
mapped keywords, although I'm sure you can make it work the way you
want given your constraints.

Kris Kowal

--
You received this message because you are subscribed to the Google Groups "nodejs" group.

[Drew Miller]

Thanks Kris; I considered that approach, and while it's obviously quite easy, it's not as pretty. More importantly, it doesn't communicate what the handler actually needs. 

Making it optional is only part of the problem; I don't want to spend time building objects per request unless the handler needs them. Again, I know I could handle that part of the problem in another way as well, but I can't think of a way that meets the (okay, my) pretty criterion. 

If we're going to spend lots of time in a framework, why not freshen it up? Starting at ugly code all day is bad for the soul.

Cheers,

Drew

[Jonathan 'Wolf' Rentzsch]

That's what I've been doing for about a year now. Just cleaned up the project for you :-)

http://github.com/rentzsch/Function.introspect.js

-jwr

[Drew Miller]

Outstanding. Thanks, Wolf.

Sent from my iPad

[tjholowaychuk]

just use a regexp :D something like this:

Function.prototype.contents = function(){
return this.toString().match(/^[^\{]*{((.*\n*)*)}/m)[1]
}

Function.prototype.params = function(){
return this.toString().match(/\((.*?)\)/)[1].match(/[\w]+/g) || []
}

var username = function(first, last){
return 'foo'
}

print(username.contents()) // => "return 'foo'; "
print(username.params()) // => ['first', 'last']

[Adam]

Wouldn't this require you to always use the same argument names for
the handle functions? This might become a problem if you want a
handler that creates a new handler but still need access to the outer
handlers arguments, however this might be a very special case.

> > On May 22, 2010 9:29 PM, "Kris Kowal" <kris.ko...@cixar.com> wrote:
>
> > On Sat, May 22, 2010 at 3:46 PM, Drew Miller <e...@anglicangeek.com> wrote:
> > > I need to get the argum...
>
> > No.  Also, bear in mind that JavaScript engines vary on how toSource a
> > function so doing this generally is even harder, and sometimes
> > impossible.
>
> > Kris Kowal
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To po...
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.

[Isaac Schlueter]

Oh, no, Doing It Wrong! Make it stop!

JavaScript doesn't give you access to the param names precisely
because this is a terrible idea. The names of the arguments are the
exclusive domain of the function itself, and not intended to be
shared. What if there's already some variable called "param" that
I've closed over, and need access to? What if I'd rather call it "p"
or "parameter" than "param" because it makes the code more clear?

You can use function.length to get the number of declared arguments
(which may not be the number of arguments that it's aware of!), or
function.name to get the name of the function (or "" if you didn't
give it one).

But keying off the argument names is just brittle cleverness of the
worst sort. Please don't do this terrible thing you're contemplating.
I *promise* you there's a better way than this madness.

Position independence and optionality means that you should use a
single object as the argument. Or, just send everything. Passing an
object handle to a function is ludicrously cheap, it's not like it has
to create a whole new object. If you *really* need to specify what's
going to e passed to the handler, you could do something like this:

// specify what gets tacked onto the single hash object
// myHandlerFn({ request : requestObject, session: sessionInfo })
webFx.handle("route", myHandlerFn, { request : true, session:true })

// or, specify which args you want, and in which order
// myHandlerFn(sessionInfo, requestObject)
webFx.handle("route", myHandlerFn, "session", "request")
// compare to this one, which gets called like:
// myOtherHandler(requestObject, sessionInfo, paramList)
webFx.handle("route", myOtherHandler, "request", "session", "param")

--i

[Drew Miller]

Thanks for the feedback Isaac. I considered all of these points before
settling on this approach.

And I would never build a framework that didn't accomodate all of
them. But it'll work for the common scenarios (mine, at least), and
there will be ways to accomodate the uncommon ones. So, 90% of my code
will easy to read and intention-revealing.

And, who does it hurt? This fx is for me, and I don't expect anyone
else to use it. If I'm wrong, there will be pain and friction in my
code and I'll change.

I've never understood why people have strong reactions to trivial or
inconsequential matters. :)

Cheers,
Drew

Sent from my iPhone

[Curtis]

I like named parameters ala objective c

On May 23, 2010, at 9:59 AM, Isaac Schlueter <i...@izs.me> wrote:

[Curtis]

I for one would be interested in whatever you come up with -
especially if you do focus on the common scenarios that you have
practical interest in.

[Isaac Schlueter]

Hey, if you want to plant grass on your carpet, more power to you. If
you ask me to tell you, in my design opinion, the best way to make it
grow, I'm going to advise you against the whole project.

On Sun, May 23, 2010 at 11:47, Drew Miller <e...@anglicangeek.com> wrote:
> And, who does it hurt? This fx is for me, and I don't expect anyone else to
> use it. If I'm wrong, there will be pain and friction in my code and I'll
> change.
>
> I've never understood why people have strong reactions to trivial or
> inconsequential matters. :)

It's because we programmers are a loving sort, and wish to spare you
that friction and pain. Also, we're opinionated jerks. So you can
pick whichever explanation you like better. :)

Sometimes you just need to do the crazy thing. I get that. Rock on.

Have you considered that this approach means you cannot use
v8::FunctionHandles from C++land as handlers?

--i

[Drew Miller]

Of course; I would expect no less than honest and forthright advice,
had I solicited it. :)

Sent from my iPhone

[Drew Miller]

I did not consider that. But, looking at 40 or so handlers in my
application, I don't anticipate that being a scenario I'll encounter.
Thanks for mentioning it though; I'll look into when I might.

Sent from my iPhone

On May 24, 2010, at 12:07 AM, Isaac Schlueter <i...@izs.me> wrote:

> Have you considered that this approach means you cannot use
> v8::FunctionHandles from C++land as handlers?

[Drew Miller]

I just re-read that, and it sounded pretty asinine. Sorry.

I don't mean to sound ungrateful. I didn't mention what I as planning to do initially because I expected this sort of admonition. I intended to just get the answer to a simple technical question. Then someone asked what I was wanting to do, and I hate to be dishonest, so I responded when I probably shouldn't have. Which takes us here.

On the other hand, you brought up one point I hadn't considered, even if it probably doesn't apply to any app I'd build with my framework. So, thanks Isaac, for the helpful advice, even if I didn't for it. ;)

Cheers,

Drew

On Mon, May 24, 2010 at 12:18 AM, Drew Miller <e...@anglicangeek.com> wrote:

Of course; I would expect no less than honest and forthright advice, had I solicited it. :)

Sent from my iPhone

On May 24, 2010, at 12:07 AM, Isaac Schlueter <i...@izs.me> wrote:

Hey, if you want to plant grass on your carpet, more power to you.  If
you ask me to tell you, in my design opinion, the best way to make it
grow, I'm going to advise you against the whole project.

On Sun, May 23, 2010 at 11:47, Drew Miller <e...@anglicangeek.com> wrote:

And, who does it hurt? This fx is for me, and I don't expect anyone else to
use it. If I'm wrong, there will be pain and friction in my code and I'll
change.

I've never understood why people have strong reactions to trivial or
inconsequential matters. :)

It's because we programmers are a loving sort, and wish to spare you
that friction and pain.  Also, we're opinionated jerks.  So you can
pick whichever explanation you like better. :)

Sometimes you just need to do the crazy thing.  I get that.  Rock on.

Have you considered that this approach means you cannot use
v8::FunctionHandles from C++land as handlers?

--i

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Debacker]

Sorry Isaac, but I don't see why

MakeTransfer(from: 123, to: 456, amount: 789);

would be any worse then

MakeTransfer( { from: 123, to: 456, amount: 789 } );

Python developers have no problem with "named" arguments, and it certainly makes code more readable than:

MakeTransfer(123, 456, 798);

Maybe it's bad because you depend on arguments' name, but otherwise you depend on arguments' order... Since JS is not statically typed, there is even greater chance of messing with arguments...

Do not that I don't like Python very much ;)

Laurent Debacker.

[Isaac Schlueter]

On Mon, May 24, 2010 at 03:18, Debacker <deba...@gmail.com> wrote:
> Sorry Isaac, but I don't see why
>
> MakeTransfer(from: 123, to: 456, amount: 789);
>
> would be any worse then
>
> MakeTransfer( { from: 123, to: 456, amount: 789 } );

Because the first one isn't JavaScript. The second one is.

If you want named position-independent parameters, the way to do that
is by passing an object which contains the relevant keys. It's
lovely.


What you *don't* want, and what python doesn't use, is something like this:

function MakeTransfer (from, to, amount) { ... }

// then, much later...
var myArgs = {from:123, to:456, amount:789}
var argNames = getArgumentNames(MakeTransfer)
MakeTransfer( myArgs[argNames[0]], myArgs[argNames[1]], myArgs[argNames[2]])

There's nothing cute about that. You can put the args in any order
(assuming that getArgumentNames actually *works*, which is a big
assumption), and you save the creation of one object (which is
incredibly cheap anyhow). But in the process, it introduces a lot of
error-prone cleverness.

--i

[Ryan Gahl]

On Mon, May 24, 2010 at 12:34 PM, Isaac Schlueter <i...@izs.me> wrote:

error-prone cleverness

redundant statement :)

btw, +1 in the "holy hell, don't do it that way" camp. At first glance it looks like you're saying you'd rather parse a function each call than create an object each call, which sounds like an overhead-negative equation to me (also the fact that you wouldn't necessarily have to create the object each call if it's a repetitive call whose options can be cached up a level or two). That's not the only reason not to do it, of course, as already explained by others. Finally, I understand the "this is how I'm gonna do it anyway so stop trying to tell me not to" mindset as we all do that from time to time; just chiming in to debate-of-the-day. As Isaac said, rock on (with your crazy ass self).

If we're going to spend lots of time in a framework, why not freshen it up? Starting at ugly code all day is bad for the soul.

Making your code brittle is not really freshening it up. This is one of those things you think is a good idea today, implement it, and then 6 months later forget you did it and wonder why some new thing you're doing isn't working how you expect. It's not something you'd want to release to anyone else either, even with good documentation on the major gotchas associated with it: "btw, to anyone using this, make sure you name your function arguments like this..."... blech.

webFx.handle("/a/static/path", function(request) { //... }

webFx.handle("a/route/with/:param, function(param) { // I don't need a request object }

webFx.handle("a/route/with/:param, function(param, request, user) { // I need the authenticated user }

webFx.handle("a/route/with/:param, function(session, param, user) { // I want session state, and order shouldn't matter }

webFx.handle("a/route/with/:param, function(session, param, user, someObjectIRegisteredViaDependyInjection) { // objects can come from many sources }

For the love of everything holy, just make webFx.handle accept a config object. Or not :)

[Drew Miller]

On Mon, May 24, 2010 at 11:29 AM, Ryan Gahl <ryan...@gmail.com> wrote:

On Mon, May 24, 2010 at 12:34 PM, Isaac Schlueter <i...@izs.me> wrote:

error-prone cleverness

redundant statement :)

Wow; I know we software engineers are prone to false generalizations, but saying clever === error-prone might be taking things too far. :)

 

btw, +1 in the "holy hell, don't do it that way" camp. At first glance it looks like you're saying you'd rather parse a function each call than create an object each call, which sounds like an overhead-negative equation to me (also the fact that you wouldn't necessarily have to create the object each call if it's a repetitive call whose options can be cached up a level or two). That's not the only reason not to do it, of course, as already explained by others. Finally, I understand the "this is how I'm gonna do it anyway so stop trying to tell me not to" mindset as we all do that from time to time; just chiming in to debate-of-the-day. As Isaac said, rock on (with your crazy ass self).

Folks, it's not brittle if I know how I write my handlers. I know that 100% of the handlers I write will work this way with the current version of Node. Yes, I understand that this would be a horrible idea of I was trying to build a generally useful framework. I'm not; I'm building something that accommodates the app I'm building in a way that *I* like, for *me.* I considered all of the points (save one) you've made, which is why I didn't initially say what I'd be doing with the knowledge requested. Cuss, I'd probably admonish me too, without context.

Oh, and *of course* I'm not parsing it per call. It gets parsed when the handler is added to the handlers collection.

 

If we're going to spend lots of time in a framework, why not freshen it up? Starting at ugly code all day is bad for the soul.

Making your code brittle is not really freshening it up. This is one of those things you think is a good idea today, implement it, and then 6 months later forget you did it and wonder why some new thing you're doing isn't working how you expect. It's not something you'd want to release to anyone else either, even with good documentation on the major gotchas associated with it: "btw, to anyone using this, make sure you name your function arguments like this..."... blech.

Yes, of course making your code brittle is not freshening it up. Anyone who asserts otherwise has serious issues. I assert that it's not brittle *for what I am building.*

I do appreciate what you and Isaac are saying about "I know you think this is a good idea today, but ..." I just don't agree (as you well know by now). Maybe in a few months I'll drop back in and let you know if the pain and friction arrived. I have *absolutely no problem* admitting when I'm wrong. :)

 

webFx.handle("/a/static/path", function(request) { //... }

webFx.handle("a/route/with/:param, function(param) { // I don't need a request object }

webFx.handle("a/route/with/:param, function(param, request, user) { // I need the authenticated user }

webFx.handle("a/route/with/:param, function(session, param, user) { // I want session state, and order shouldn't matter }

webFx.handle("a/route/with/:param, function(session, param, user, someObjectIRegisteredViaDependyInjection) { // objects can come from many sources }

For the love of everything holy, just make webFx.handle accept a config object. Or not :)

That's what I had, and it hurts my eyes. And, if I'm wrong and this approach hurts me as you expect it will, I'd go back to my last impl', pushing values onto this with call. Building this.aValue(callback), even for very expensive per-request values, performs just as well as the (commonly-held insane) approach I've settled on. It's just not as pretty.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Ryan Gahl]

On Mon, May 24, 2010 at 1:45 PM, Drew Miller <e...@anglicangeek.com> wrote:

I'm building something that accommodates the app I'm building in a way that *I* like, for *me.*

Yeah, we all get that, and at the end of the day that trumps all the arguments from us hotheads. As Isaac said so eloquently, we programmers are opinionated jerks (btw, Isaac, loved that bit). And I get the "it's not brittle for me because I'm going to remember that this is there forever and ever, amen" argument as well. For some things, that's just true, or remains true for as long as it matters. I guess we're just saying that this falls within the _class_ of things that most would consider brittle because there is at least _some_ chance that you or someone else using it could forget the special rules and as you put it, cause friction and pain. Doing it the config object way simply removes that possibility, thus is less brittle as a general approach.

-ryan

[Drew Miller]

Agreed. And, I certainly empathize with being an opinionated jerk; were I not one, I'd have let this go several posts ago. :)

[Mikeal Rogers]

Hate to continue flaming this but, you know, i kinda have to :P

JavaScript doesn't have this level of introspection and that is
intentional it's not an oversight or a bug.

Don't build APIs that depend on features a language doesn't have, it's
a very bad practice. Write an API for JavaScript the way JavaScript
supports it, not something that looks like Python/Ruby.

-Mikeal

[Debacker]

I know it's no JS, I thought that the debate was about named paremeters in general.

Of course a "getArgumentNames" function is not clean.

So we agree that MakeTransfer(from: 123, to: 456, amount: 789); would be syntactic sugar, but yet is not supported ;)

[Dean Landolt]

On Mon, May 24, 2010 at 3:19 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

Hate to continue flaming this but, you know, i kinda have to :P

JavaScript doesn't have this level of introspection and that is
intentional it's not an oversight or a bug.

Don't build APIs that depend on features a language doesn't have, it's
a very bad practice. Write an API for JavaScript the way JavaScript
supports it, not something that looks like Python/Ruby.

Exactly...

The reason it's brittle is because V8 could up and change Function.prototype.toString and that couldn't possibly be considered a bug.

But carry on -- you're certainly aware of the risks.

[Drew Miller]

On Mon, May 24, 2010 at 12:19 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

Hate to continue flaming this but, you know, i kinda have to :P

JavaScript doesn't have this level of introspection and that is
intentional it's not an oversight or a bug.

Don't build APIs that depend on features a language doesn't have, it's
a very bad practice. Write an API for JavaScript the way JavaScript
supports it, not something that looks like Python/Ruby.

Sorry, but if I can do it, and get way with it, I can do it by definition. If everyone followed guidance, this would be an awfully boring world. :)

(Oh, and I'm not trying to "look like" anything; I'm twisting a platform (Node) to do what *I* want it to do in a certain context. It's fun to twist platforms and frameworks. Sure, sometimes they spring back and smack you in the face. That's cool, too. I imagine you've twisted a framework or two of your own if you crafted software for a significant length of time; it's just, when you did it, it was for *your* context. :P)

[Mikeal Rogers]

*sigh*

Everything Crockford has ever said about "the ninjas" is flying
through my brain right now.

[Drew Miller]

I bet you're all Apple-sympathizers, too!

 

(It's a joke!)

[Drew Miller]

Okay, that's a low blow. Well played, sir. :)

[Ryan Gahl]

On Mon, May 24, 2010 at 2:31 PM, Drew Miller <e...@anglicangeek.com> wrote:

I bet you're all Apple-sympathizers, too!

Yes, I do feel sorry for Apple.

[Ricardo Tomasi]

Lovely thread ;)

Allow me to barge in, why not pass a plain object as argument? You get
the same result but "namespaced" (which looks nicer to me):

webFx.handle("a/route/with/:param, function(request) {
// request.user, request.param, request.session...
});

cheers,
Cap. Obvious

ps: I guess Drew will think twice before revealing his ideas next
time.

[Drew Miller]

On Mon, May 24, 2010 at 1:11 PM, Ricardo Tomasi <ricar...@gmail.com> wrote:

Lovely thread ;)

It is lovely, isn't it?

 

Allow me to barge in, why not pass a plain object as argument? You get
the same result but "namespaced" (which looks nicer to me):

webFx.handle("a/route/with/:param, function(request) {
  // request.user, request.param, request.session...
});

Ricardo, what you proposed doesn't solve signaling to the framework what values are needed; it only solves position independence and optionality. Also, what you proposed it not significantly different than pushing values onto this with call (what I'm already doing).

 

cheers,
Cap. Obvious

ps: I guess Drew will think twice before revealing his ideas next
time.

No, Drew will most certainly *not* think twice; I live for this stuff! Civil discussions about differences in opinion are a great deal of fun. And, they often lead to important lessons.

[Isaac Schlueter]

On Mon, May 24, 2010 at 13:21, Drew Miller <e...@anglicangeek.com> wrote:
> [an object argument] doesn't solve signaling to the framework what

> values are needed; it only solves position independence and optionality.
> Also, what you proposed it not significantly different than pushing values
> onto this with call (what I'm already doing).

You know, YUI does this with the YUI().use() call. It's sort of a
combination of an object argument and a stated list of requested data.
It's pretty, avoids all the problems you're complaining about,
doesn't depend on any language features that aren't in JS, and works
well.

YUI().use("foo", "bar", "baz", function (Y) {
Y.foo()
Y.bar()
Y.baz()
// etc.
})

You could also do something like this:

webFx.handle("route", "request", "param", "session", function (req, prm, sn) {
doSomethign(req, prm, sn)
})

--i

[Drew Miller]

Ah, that's interesting. Not as elegant, but closer than what I have today, and it's kosher. I'll definitely think about that, or something similar. Thanks Isaac.

[Drew Miller]

Of course, it's not really that different from a requestor (or as Ryan said, a configuration) object, and it's not DRY. Still, it does hurt my eyes a bit less, for some reason I can't put my finger on.

[inimino]

On 2010-05-24 14:21, Drew Miller wrote:
>> webFx.handle("a/route/with/:param, function(request) {
>> // request.user, request.param, request.session...
>> });
>
> Ricardo, what you proposed doesn't solve signaling to the framework what
> values are needed; it only solves position independence and optionality.
> Also, what you proposed it not significantly different than pushing values
> onto this with call (what I'm already doing).

Since you are using V8, you can use getters to only generate values
when they are needed.

--
http://inimino.org/~inimino/blog/