Firefox, get with it.
The JavaScript engine in Firefox has some really asinine warnings, here's the one that annoys me most:
deprecated with statement usage:
with ({stuff: "here"}) { eval("alert(stuff)"); }
Ok, now this is just lame. with is clearly in the ECMA standard and all JavaScript implementations, is definitely useful, and it can't go away while still maintaining backwards compatibility. It provides functionality that simply can't be offered any other way since you don't have access to the namespace objects from the script side of the interpreter.
Now I can hypothesize the reasoning for wanting to deprecate this syntax, but it's not necessary. I imagine that someone decided that with is slowing the whole language down since usage of it or eval basically requires a hash table (or equivalent) implementation of the function local namespace. Sure, that's true, but on a per-function basis.
If we assume that eval becomes a keyword at some point, they could simply mark functions that use either with or eval as needing a dynamic namespace. Everything else could use an optimized locals implementation (like Python's). The majority of JavaScript code can have a theoretically faster implementation, the rest stays the same speed, and nothing breaks. While you're at it, let us introspect local namespaces like Python allows with locals() so we can put together our own debugger without hacking the interpreter; Venkman is obnoxious.
In ECMA-262 Edition 3, |eval| basically is a keyword: you can call it directly, but you can’t read or write the property otherwise and you get an error (exception) if you try. It’s not a global keyword, in that you can use it as a variable or property name — without having to resort to quoting["tricks"]– but I think we’re generally moving towards context-dependent keywords anyway (see get/set, f.e.).
The deprecation of the |with| statement has a long and storied history related in part, as you suspect, to optimization concerns, though I also dimly recall there being other issues as well. My recollection is not strong enough for me to be comfortable speculating, but I’ll ask Brendan to remind me later. (Some of those other issues, such as the meaning of function statements within |with| scopes, may have been resolved in edition 3, in fact.)
There remain a few edge |with|-cases for which no clear workaround comes to mind (Jesse Ruderman’s JS console has some), indeed. I wonder if we might remove that warning, as we did with var-redeclaration prior to 1.5.
Also, in the Mozilla JS engine, we do in fact detect at compilation time whether a function uses |eval|, |with|, or other constructs which would require a “heavyweight” activation. The rest get a faster and less memory-intensive invocation path.
Comment by Mike Shaver — 2005-12-17 @ 1:19 pm
Why all this anger over a strict warning that’s not on by default?
The warning has nothing to do with optimization hardships arising from with and eval. We already optimize argument and local variable access if neither of these constructs is used. We already treat eval as a keyword without reserving it. Python didn’t pioneer this space, Lisp did. The techniques are well-known, contrary to what your rant implies.
The reasons for the warning are documented at http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:with. With is hazardous in practice, in real-world JS I’ve seen. But it can be used well too, like any tool. You are right that it’s not going away, ever. If you think this strict warning should be removed, please file a bug (https://bugzilla.mozilla.org/). I would be happy to hear what other warnings you think are “asinine”, or just not helpful.
Venkman is many things, but it’s just software. Software can’t be obnoxious, but people can be. Take it easy,
/be
Comment by Brendan Eich — 2005-12-22 @ 9:42 am
The annoyance is that when developing JavaScript code, you’re going to want to have warnings turned on because sometimes they’re helpful. The thing that bothers me about this warning is that it’s the mere usage of a language feature. So what? I’d rather get a useful warning, like using an assignment as a conditional expression without an extra set of parentheses (which is often a harmful typo of ==).
The other one that regularly bothers me is the warning related to declaring global variables without “var”. I understand why it’s a warning, but I legitimately need that code to be structured in exactly that way to work around a really obscure JScript bug for IE compatibility.
Superfluous warnings annoy me because there will often be quite a few of them each page load, and can hide real warnings rather well.
I wasn’t implying that Python’s locals implementation pioneered anything, only that it has an optimized locals implementation that allows for eval and full interpreter-side introspection. JavaScript desperately needs better introspection.
As for software being obnoxious, I beg to differ. Oxford defines obnoxious as “extremely unpleasant”. While you may find me obnoxious, there’s no grammatical reason why Venkman can’t also be.
Comment by bob — 2005-12-26 @ 6:57 pm
I don’t think you are obnoxious — you’re a breath of fresh air! I’m first to say Python > JS, but JS ain’t going away, and it needs to evolve by standing on others’ shoulders. My roadmap blog says more.
There’s a lot of suck in JS because it was a rush job (
Comment by Brendan Eich — 2006-01-03 @ 1:49 pm
Looks like entering a less-than verbatim killed most of my comment, but I hope Bob can resurrect it.
/be
Comment by Brendan Eich — 2006-01-03 @ 3:56 pm
Looks dead to me, seems like WordPress strikes again.
Comment by bob — 2006-01-03 @ 6:06 pm
Ok, from memory here’s what I wrote, for history buffs:
There’s a lot of suck in JS because it was a rush job: less than two weeks of hacking in May 1995, after which I spent the rest of the year embedding the VM into the non-reentrant, manual-allocation-hazard-ridden pile that was the Netscape 2 browser codebase. I said as much last fall in an ACM ICFP keynote. The result of the embedding hack-job became known as the DOM “level 0″, which has yet to be standardized, which IE screwed up variously in cloning, but which all web apps and many pages depend on in detail. It is finally being spec’ed by http://www.whatwg.org.
It got worse as Netscape succumbed to MS’s monster-truck-vs-yugo attack and Netscape’s own mismanagement and acquisition frenzy. The language was standardized prematurely, based on what interoperated in 1996. A few ideas (first-class functions, objects as string=>value hashes) had become tired workhorses. Lack of special forms (or normal forms, as you point out elsewhere) for bound methods, constructors, and iterators hurt.
But the ECMA standardization initially didn’t fix any of these problems, because it was trying to codify existing practice. This is a good thing in standards where the market is leading the standard, but after Netscape crapped out, JS stagnated. The major increment of Edition 3 (1999) added a bunch of hardcoded stuff that should have been bootstrapped in a standard library, again failed to fix the early under-design problems, and generally was a mixed bag.
Imagine if Python circa Spring 1995 were frozen, then updated again only once, by a committee, three years later. Sucked to be me, so I went off in late 1997 to help found mozilla.org.
But I’m back on ECMA TG1 now, and we are working on a better version, Edition 4 (AKA JS2). I’d like to steal liberally from Python in a bunch of ways, including generators. If you want to talk about any of this more, feel free to drop me an email or comment on my roadmap blog.
/be
Comment by Brendan Eich — 2006-01-04 @ 4:58 pm
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=322430 to get rid of that with strict warning.
/be
Comment by Brendan Eich — 2006-01-04 @ 6:46 pm
Fixed for Firefox 1.5.0.1 (a patch-update, not whole-app, release due by end of month).
/be
Comment by Brendan Eich — 2006-01-16 @ 6:18 pm