On Jun 16, 2008, at 10:48 PM, Mark S. Miller wrote:
On Mon, Jun 16, 2008 at 10:19 PM, Brendan Eich
<[EMAIL PROTECTED]> wrote:
I am not going to repeat what I wrote at an earlier point in this
thread (13
June at 10:24) -- you didn't reply to what I wrote then. Did that
message
not reach you?
Are you referring to
<https://mail.mozilla.org/pipermail/es3.x-discuss/2008-June/
000108.html>?
Yes.
It was the closest match I could find. I responded to this message.
What remaining point in this message do you feel still needs to be
addressed? I'm not being difficult. I just reread this message and
couldn't spot it.
You replied only to the bit about reformed with, where I wrote:
"Reformed with" was an attempt to restore lexical scope by exact
type annotation. That's what people voted down, not the ES1-3
"with" statement.
but that was not the main point (since reformed with was withdrawn),
it was just setting the record straight ("reformed with", not "strict
with" -- and the fact that it was voted down with red on the
spreadsheet does not argue against plain old "with" being allowed in
strict mode).
The main point was that (a) 'with' is widespread and popular;
therefore (b) strict mode that bans 'with' could fail to be used.
The question isn't whether an existing statement is "good enough",
it's
whether a strict mode that bans it is "usable enough".
A strict mode which doesn't ban is clearly not.
Why "clearly"? Usability depends on users and "ergonomics". Something
about 'with' is usable enough that users persist in writing programs
using it. These users say (when they speak up coherently at all) that
'with' makes the language more convenient. Well-known JS hackers say
this, to me even, and get annoyed by nagging such as was found in
older Firefoxes (console warnings about "deprecated with").
If you get rid of "with", then the static analysis rule in ES4 becomes
very simple: all free variables in a program (script, compilation
unit, whatever) are global references, to be looked up as properties
of that program's global object, whether or not those properties are
present.
That allows lexical-reference typos through to run-time, where they
become errors -- that is not something the old, withdrawn strict mode
in ES4 allowed.
It's true that 'with' prevents analysis from deciding where a free
name will be found, but with the old strict mode, that's actually a
useful escape hatch. Otherwise (no 'with') the name would have to
resolve to a compiler-visible global definition, or you would have to
reach for eval.
This old notion of strict mode was to be an optional feature, at the
implementation's discretion. We dropped it in favor of 'use
strict' a la
Perl -- "use good taste and sanity".
And is "with" either in good taste or sane?
I avoid 'with', but I try not to confuse my taste with others' tastes
(plural), or with necessity. Why is it necessary for strict mode to
ban 'with'?
The global object makes the contents of the global scope unknown. But
it does not ambiguate which variable name occurences are to be
interpreted as references into this global scope. Without "with", ES4
strict scopes would be statically analyzable. I'm surprised you're
willing to give that up.
As I wrote previously, all browser implementations have to support
'with' and deoptimize code in its body. There's no savings to be had
in rejecting it from strict mode, and doing so takes a tiny bit of
extra code. On the other hand, such a strict mode may be less used
than 'with', because of 'with' perduring.
Is 'with' any worse than eval, for the purposes of the analysis you
have in mind, if you already allow the "operator" form of eval in
strict mode?
so is kicking 'with' out of
strict mode worth it, especially if it impairs adoption of "use
strict"?
Yes. Otherwise I don't see the point of "use strict".
Can you define the point of "use strict" other than by appealing to
taste?
/be
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
