inserting variable into the current lexical scope

[weepy]

I think there might not be a way round this. I'm trying to insert variables from another scope into the current scope as local variables like so:

var vars = { a: 1, b: 2}
function mixin() {
  for(var i in vars)
    eval("var " + i + "=" + vars[i])
}
(function() {
  mixin()
  console.log(a)
})()

Obviously this doesn't work since "eval" is outside the closure. But there doesn't seem to be a way to reference the current lexical scope. Even mixin.call(this) wouldn't work.

As I said above, I'm not sure there's an easy round this - even for Coffee, but I'd be interested in all your ideas.

Cheers

J

[matehat]

Well, that'd really be feasible in coffeescript. We could have a global operator that inject the variables of an object into the local scope. If people show an interest, I'd be happy to produce a patch for that.

[weepy]

So how might you rewrite the example above?

[matehat]

We could have a keyword, maybe something like use or mixin or whatever, that, with an object, transforms into (disclaimer: naive implementation ...) :

use obj

=>

for (k in obj)
  eval("var " + k + "= obj[" + k + "]");

Which would imply you'd be able to write your example as :

vars: { a: 1, b: 2}

(->
  use vars
  console.log a
)()

[jashkenas]

matehat: I'd be interested in seeing your implementation as well. Tim_Smart and I have talked a lot about sandboxing in JS and the dynamic creation of local variables, but outside of with or eval, I don't know of a good way to create local variables in JavaScript when you don't know their name in advance.

If we could have dynamic local variables, it would greatly improve the process.mixin alternatives, and could really enable some nice DSL-style libraries without polluting the scope of other files.

[matehat]

Hmm, maybe I'm seeing to simple then. I might be missing something obvious :P

[weepy]

That might well be quite useful . It does use "eval" - but that doesn't really matter here.

[silentmatt]

This is basically the same thing that with does. The only difference I can see is that with won't overwrite any of the variables that are already in scope; it would just hide them.

[matehat]

that's the idea. Anyway, we had a talk on #coffeescript and decided, for performance issues (real ones), that it should not be in the core. Sorry weepy ...

[weepy]

I'd be interested to know what the performance issues were ? As far as I knew - the eval would occur just once.

[matehat]

It would for the usual case, but if it is in the core, it's kind of as if we proposed it as a good option in general, even in recurring or iterative situations. After some benchmarking, the ratio in performance between normal and evaled assignment is between 150 to 2000! That's pretty big ..

A thing that could make us overcome this is if the syntax were more precise on what we want to use from an object :

from vars use a, b

That would not require us to use the eval directive and we could avoid the perfomance issue. If people show an interest, that would be feasible.

[weepy]

Yes that's kinda cool. But I suppose it's not much terser than

a: vars.a; b: vars.b 

?
Regarding performance - I found that you could significantly improve performance by only performing 1 eval:

O = {a:1,b:2,c:function()  {} }

for(var i=0; i< 100000; i++) {  var a=O.a, b=O.b, b=O.c; }
244 ms
0.024ms per iteration

for(var i=0; i< 100000; i++) {  eval("var a=O.a, b=O.b, b=O.c;") }
570ms
0.057ms per iteration

Which is only twice as slow ? Given that a "using" statement wouldn't typically be called that often compared with looped code, I don't think that's signifcantly slow ?

[matehat]

What I thought would be nice in explicit injection like the above, is that it could offer the from a use * alternative, where we could emphasize on how more restrictive is better for most situation, regarding performances.

Sure, it does not look so much terser, but injecting 5 variables in your alternative does get kinda awkward. A direct application of this whole issue is module sandboxing and in that case, we don't always need 20 names or so to be imported and such a syntax would still look clean with 5-7 names injection.

[matehat]

In your example, I get 65k ops/sec for vanilla and 471 for eval'ed one .. so that's more a factor of around 140 times faster for vanilla.

[weepy]

Funny we get different amounts of performance - what browser are you running on (mine is FF 3.6 - so it probably ) ?

Point taken on the from .... idea, and the idea about from a use * is interesting- meaning that it would be easy to optimize it if you wanted to. (Perhaps: use * from A might read nicer)

We should also get a better handle on whether it really would be a performance issue - it really depends on use. It's not relative speed compared with naked assignment that's important here - but time taken relative to the rest of the functionality of the program.
My feeling is that really the "use" type keyword is only likely called a few times in a program's life cycle, (if you imagine how it's often used in something like Ruby) - so it might not be such an issue.

[weepy]

Here's a nice example of where this is useful for cleaning up, using matehat's suggestion:

(->
  MyClass: {
    map: (object, callback) -> 
      items: []
      each(object, (i) -> items.push(callback.apply(@, arguments))
      items
    each: (object, callback) -> 
      for v,i in object
        callback(i)
  }

  use MyClass *
  # or 
  use MyClass each, map

  # export
  @MyClass: MyClass
)()

As you can see it mixes in the module's method's to itself, meaning it can refer to them simply by itself without the MyClass prefix.

This example was adapted from : http://dailyjs.com/2010/03/19/private-vars-scope/