Hacker News Reader

Comment by robocat | Hacker News Reader

It also requires that comments get stored and waste memory: previously just enough of the AST needed to be stored to be able to regenerate the JavaScript. You can't throw away the comments because you can't predict where code might do someVarHoldingAFunc.toString()

It seems like an unnecessary change - if the source needs to be accessed then get the source file.

View on HN

ES doesn't store quite enough of the AST to recreate the function anyway. Most functions reference variables and functions defined in a lexical scope outside themselves. Getting the source with toString(), and passing that to eval(), doesn't reproduce the function, and sometimes it compiles ok but the function does the wrong thing.

Usually it doesn't matter, because these methods are used on functions that luckily only use well known names, mainly properties of window/global.

But it's a risk, and I've seen subtle bugs caused by the assumption that the function's .toString() can be run through text substitutions and eval to get back a variant of the original code.

Contrived example:

  let x = "wrong variable";

  function f() { let x = "I am x"; return function g() { return x; } } 
  f()()
  => 'I am x'
  
  eval(f().toString())
  g()
  => 'wrong variable'

Agreed. I guess the argument for it is it's more accurately reflected but... who cares? Maybe I'm not understanding what people do with [function].toString() in the real world.

What's even worse is that now frameworks (and viruses) will store data in comments.

I know this because I have wanted to use fn.toString() as part of some meta-programming many years ago (but couldn't because comments were not stored).

I am sure a lot of effort went in to making a good decision, aiming for a good outcome, but this smells like a bad one.

Engines hold the entire source anyway, with the exception of XS, which returns "[native function]" for everything.

Reply on news.ycombinator.com