4 ms·

I haven't read the book, but this praise of with statements struck me as odd: "The portions of this book that cover features that are relatively un-changing, su

by ville 14y ago

I haven't read the book, but this praise of with statements struck me as odd: "The portions of this book that cover features that are relatively un-changing, such as code evaluation, with statements, and timers are continually being used in interesting ways." There also seems to be even a whole chapter in the book dedicated to with statements. What are those interesting and great applications that justify this feature, being considered harmful[0] and even removed from the language in strict mode of ES5? [0] http://www.yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/ http://www.yuiblog.com/blog/2006/04/11/with-statement-consid...

jeresig 14y ago
Every where you see the "with statements are harmful"/"eval is harmful" drum being hit, you see Douglas Crockford. He's a great guy, and I really respect his opinion, but I continue to feel that these are legitimately useful aspects of the JavaScript language -- especially if we want to consider JavaScript as the "assembly language" upon which other languages are built. For with statements in particular, templating and scoped evaluation (I provide an example from the Firebug console in the book) are probably the two areas in which I've seen it most successfully used. For code evaluation I only have to direct you to the creation of Coffeescript (an entirely evaluated language) whose innovations have directly influenced new versions of the ECMAScript language. They have their place and when used sparingly, but effectively, the can be formidable parts of a web developer's arsenal.
- ville 14y ago
  I agree that code evaluation is a valuable feature in the language. But to be accurate, I wouldn't call CoffeeScript an entirely evaluated language, since it's mainly meant to be used by pre-compiling it to JS. (From CoffeeScript website: "While it's not recommended for serious use, CoffeeScripts may be included directly within the browser") Anyway the ability to eval code on the browser is awesome for trying it out or for building an IDE.
- jashkenas 14y ago
  I agree with what you're saying, but I'd also be remiss if I didn't quibble with this bit: > For code evaluation I only have to direct you to the creation > of Coffeescript (an entirely evaluated language) whose > innovations have directly influenced new versions of the > ECMAScript language. The standard way to use CoffeeScript is to compile it to JavaScript first, and then deploy and run with that. There's zero "eval()" involved. Or rather, doing direct "eval()" of CoffeeScript is possible, and on occasion fun, but is discouraged for all the usual reasons.
- davej 14y ago
  There are some peculiarities with the `with` statements, but mainly it is just dog-slow compared to a standard lookup. Last time I checked it was 200-300 times slower to use the `with` statement rather than just doing an `obj.key` lookup. If nothing else, surely it should be avoided in production purely for performance reasons.
- bzbarsky 14y ago
  The problem is that "with" statements basically disable lots of JIT optimizations in actual implementations, with browsers either falling back to a much slower baseline jit or running the function containing "with" entirely in an interpreter. So they _can_ be used effectively if one really knows what one is doing, but they're a bit of a footgun.
tikhonj 14y ago
I don't know about actual uses, but I was thinking about a very hypothetical one: pattern-matching. I like my languages to have some sort of pattern matching; however, to make it work properly you have to be able to add variables to the local scope programmatically. With statements are JavaScript's way of letting you access the local scope in a dynamic but limited way. You can imagine code like: function () { with (match("Foo a b")) { return a + b } with (match("Bar a b")) { return a - b } } This would let you have basic pattern matching. Of course, this would also necessitate adding constructors (in the pattern-matching sense) to the language, so it would be fairly complicated. A simple option would be to just support lists and objects: function () { with (match("[a, b]")) { return a + b } with (match("[a]")) { return a } with (match("[]")) { return 0 } } You could imagine this syntax being streamlined a bit. Basically, the with statement gives you a bit of access to the variable scope which is very useful in adding features to the language. It isn't quite as flexible as some alternatives (e.g. macros) but it can still be useful.
libria 14y ago
Michael Bolin (author of Closure, definitive guide) gave a presentation advocating the use of "with" for a particular problem: http://bolinfest.com/talks/2011/jsconf.us/#1 http://bolinfest.com/talks/2011/jsconf.us/#1
- isnotchicago 14y ago
  How is the proposed usage (slide #8) different than the bad usage on slide #4 ("shorthand for setting multiple properties on an object")? The code for sharing module scope works fine as long as you stick with "a.i" instead of just "i" (i.e., are not lazy). As mentioned elsewhere, using `with` is very slow: http://jsperf.com/with-versus-without http://jsperf.com/with-versus-without

by ville 14y ago

jeresig 14y ago

Every where you see the "with statements are harmful"/"eval is harmful" drum being hit, you see Douglas Crockford. He's a great guy, and I really respect his opinion, but I continue to feel that these are legitimately useful aspects of the JavaScript language -- especially if we want to consider JavaScript as the "assembly language" upon which other languages are built. For with statements in particular, templating and scoped evaluation (I provide an example from the Firebug console in the book) are probably the two areas in which I've seen it most successfully used. For code evaluation I only have to direct you to the creation of Coffeescript (an entirely evaluated language) whose innovations have directly influenced new versions of the ECMAScript language. They have their place and when used sparingly, but effectively, the can be formidable parts of a web developer's arsenal.

ville 14y ago
I agree that code evaluation is a valuable feature in the language. But to be accurate, I wouldn't call CoffeeScript an entirely evaluated language, since it's mainly meant to be used by pre-compiling it to JS. (From CoffeeScript website: "While it's not recommended for serious use, CoffeeScripts may be included directly within the browser") Anyway the ability to eval code on the browser is awesome for trying it out or for building an IDE.
jashkenas 14y ago
I agree with what you're saying, but I'd also be remiss if I didn't quibble with this bit: > For code evaluation I only have to direct you to the creation > of Coffeescript (an entirely evaluated language) whose > innovations have directly influenced new versions of the > ECMAScript language. The standard way to use CoffeeScript is to compile it to JavaScript first, and then deploy and run with that. There's zero "eval()" involved. Or rather, doing direct "eval()" of CoffeeScript is possible, and on occasion fun, but is discouraged for all the usual reasons.
davej 14y ago
There are some peculiarities with the `with` statements, but mainly it is just dog-slow compared to a standard lookup. Last time I checked it was 200-300 times slower to use the `with` statement rather than just doing an `obj.key` lookup. If nothing else, surely it should be avoided in production purely for performance reasons.
bzbarsky 14y ago
The problem is that "with" statements basically disable lots of JIT optimizations in actual implementations, with browsers either falling back to a much slower baseline jit or running the function containing "with" entirely in an interpreter. So they _can_ be used effectively if one really knows what one is doing, but they're a bit of a footgun.

tikhonj 14y ago

I don't know about actual uses, but I was thinking about a very hypothetical one: pattern-matching. I like my languages to have some sort of pattern matching; however, to make it work properly you have to be able to add variables to the local scope programmatically. With statements are JavaScript's way of letting you access the local scope in a dynamic but limited way. You can imagine code like: function () { with (match("Foo a b")) { return a + b } with (match("Bar a b")) { return a - b } } This would let you have basic pattern matching. Of course, this would also necessitate adding constructors (in the pattern-matching sense) to the language, so it would be fairly complicated. A simple option would be to just support lists and objects: function () { with (match("[a, b]")) { return a + b } with (match("[a]")) { return a } with (match("[]")) { return 0 } } You could imagine this syntax being streamlined a bit. Basically, the with statement gives you a bit of access to the variable scope which is very useful in adding features to the language. It isn't quite as flexible as some alternatives (e.g. macros) but it can still be useful.

libria 14y ago

Michael Bolin (author of Closure, definitive guide) gave a presentation advocating the use of "with" for a particular problem: http://bolinfest.com/talks/2011/jsconf.us/#1 http://bolinfest.com/talks/2011/jsconf.us/#1

isnotchicago 14y ago
How is the proposed usage (slide #8) different than the bad usage on slide #4 ("shorthand for setting multiple properties on an object")? The code for sharing module scope works fine as long as you stick with "a.i" instead of just "i" (i.e., are not lazy). As mentioned elsewhere, using `with` is very slow: http://jsperf.com/with-versus-without http://jsperf.com/with-versus-without