On Mon, Apr 18, 2011 at 3:12 AM, Oliver Hunt oli...@apple.com wrote:
An implementation _could_ add a mode (*shudder*) along the same lines as
strict mode:
die in hell ASI, i hate you with the fiery passion of a thousand burning
suns.;
And then make it a syntax error whenever ASI would
Javascript closures bind their free variables by reference;
what does that mean for const functions?
..
var real_f;
const f() { return real_f(); }
I Claus, I'm not sure why this isn't obvious in the current spec. Please
let me know what needs to be modified so that it becomes
- there is no rule-of-thumb understanding (programmers
have to look up or memorize all restricted productions,
Here is a quibble: there is a rule, or set of rules
.. Not quite as bad as you wrote.
Sorry, I didn't notice that my attempted summary could be
read as dramatizing the issue!-) The
On 18/04/2011, at 09:52, Peter van der Zee wrote:
On Mon, Apr 18, 2011 at 3:12 AM, Oliver Hunt oli...@apple.com wrote:
An implementation _could_ add a mode (*shudder*) along the same lines as
strict mode:
die in hell ASI, i hate you with the fiery passion of a thousand burning
suns.;
And
On Mon, Apr 18, 2011 at 12:34 PM, Jorge jo...@jorgechamorro.com wrote:
What am I missing ?
As far as the directive goes, they are opt-in. Old code won't be opting in.
Other than that they have the same issues as use strict might have.
- peter
___
On 18/04/2011, at 13:10, Peter van der Zee wrote:
On Mon, Apr 18, 2011 at 12:34 PM, Jorge jo...@jorgechamorro.com wrote:
What am I missing ?
As far as the directive goes, they are opt-in. Old code won't be opting in.
Other than that they have the same issues as use strict might have.
But
Hi Everyone,
Just to add some out-of-the-browser perspective to the discussion, and since
Node.js was mentioned by name in this thread, I believe it is important to
note that the package manager for Node.js absolutely *depends* on the
automatic semicolon insertion working just the way it works
Jorge, I would opt in for warnings e.g. if I planned on minifying my
web app in the future. Most web apps will burn in hell if they are
missing semicolons when you minify them.
On 04/18/2011 02:42 PM, Jorge wrote:
On 18/04/2011, at 13:10, Peter van
2011/4/15 Sean Eagan seaneag...@gmail.com
I think it might be better anyway to switch
to a single object argument for all traps so that the order becomes
irrelevant, of course the argument names then become relevant, so it's
a tradeoff.
Any comments on this idea?
I don't think the
Good minifiers will not have a problem to perform ASI themselves.
Browsers are not intended to check the code that is sent to them. They
should try to compile and run the code as fast as possible, and not try
to do code analytics for the developer. If you want to perform code
analytics, use an
On Apr 17, 2011, at 6:07 PM, Garrett Smith wrote:
On 4/17/11, Brendan Eich bren...@mozilla.com wrote:
On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
[TLDR]
ASI is not going to be removed. I don't know why you think it could be.
Why not? Iif developers would stop doing that then
On Apr 17, 2011, at 6:44 PM, Dmitry A. Soshnikov wrote:
The question is not that it's hard or not. IMO an explicit semicolon is
really a syntactic noise in the language. In goes to the early era of
C/Pascal, etc.
No, much earlier. Algol 60 used semicolons as separators (not terminators),
See http://www.mail-archive.com/es-discuss@mozilla.org/msg05609.html and
earlier posts in that thread, for where
no asi;
as a Harmony pragma was tossed out as possible syntax.
The agreement we seemed to reach was simply to have a way for programmers to
disable ASI, not try a complex new-ASI
On Apr 18, 2011, at 12:24 AM, Garrett Smith wrote:
Implementations are motivated to get scripts working and conform to
specs. How could Ecma encourage developers to stop using ASI? I
initially thought that standard warnings in strict mode would help.
No. My earlier reply to your previous post
On 2011-04-18, at 13:48, Brendan Eich wrote:
Do popular minifiers still not parse and insert semicolons (and remove
newlines) as needed?
Only the broken ones! :)
___
es-discuss mailing list
es-discuss@mozilla.org
Hi Dave,
thanks for your reply. I was beginning to fear that these
suggestions had been missed. Let me start directly with
your main point, because it biases the detailed evaluation:
* making nested callbacks better via all of the above
I think this is a deeper problem that can't be solved
On Apr 18, 2011, at 1:45 AM, Claus Reinke wrote:
The bigger problem is not the rule-space but the mixed significance and
insignificance of line terminators.
..
.. The line terminator having selective meaning due to ASI as an error
correction procedure, and of course in restricted
On Apr 17, 2011, at 9:09 AM, David Herman wrote:
* functions with expression bodies
This was proposed for ES4 and implemented in SpiderMonkey. I believe there
are some unfortunate ambiguities in the grammar that came up, and I think
they've been treated as moribund. But I love them, and
On Mon, Apr 18, 2011 at 05:42, Jorge jo...@jorgechamorro.com wrote:
I understand that it would be quite interesting to get a warning/error in
this case:
a= b
(c= d)();
...only that there's no ASI in this case !
Jorge touches on the reason why the whole debate about ASI is a bit
misguided, in
On Mon, Apr 18, 2011 at 11:05, Brendan Eich bren...@mozilla.com wrote:
Given the primary problem is not ASI but its absence where users expect it
due to mistakenly believing a newline is significant, one could argue the fix
is not to ban ASI and tax everyone with writing lots of insignificant
On Mon, Apr 18, 2011 at 12:22, Brendan Eich bren...@mozilla.com wrote:
I agree, but in a friendly spirit suggest typing ; is a tax too, however much
lesser.
True, I overstated. It *is* a keyboard tax. But (at least in my
experience) I tend to type code in a moment, and then read it for the
On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote:
Hello everyone,
My idea is to disallow overwriting of === operator, and make 'compare'
operator implement == instead. Why?
1. === means for me that two variables have reference to the same
object, so there is no point of overwriting
I don't think the traps take that many arguments that they merit a
keyword-arguments API.
Agreed, the quantity of arguments, even if one were to be added, is
manageable without keyword arguments. However, if any arguments need
to be selectively added to certain traps in the future, then the
Well, I don't think ES5 has anything to say about this issue because as you
know it doesn't include the concept of multiple global contexts. I actually
don't think it is valid to try to interpret the ES5 spec. to try to find
guidance on this issue as anything thing you find that may seem
On Apr 18, 2011, at 2:28 PM, Mark S. Miller wrote:
Good. I went through a similarly indirect analysis, reading between the
lines, and arrived at the same conclusion for canary.html and
canary-orig.html. As for canary-direct.html, I think both FF4.0's apparent
behavior (it is a direct
On Mon, Apr 18, 2011 at 6:08 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 18, 2011, at 2:28 PM, Mark S. Miller wrote:
Good. I went through a similarly indirect analysis, reading between the
lines, and arrived at the same conclusion for canary.html and
canary-orig.html. As for
Le 18/04/2011 21:55, Sean Eagan a écrit :
Storing proxy instance state directly within handlers:
==
Trap namespace pollution:
The default handler, Proxy.Handler, stores proxy instance state
directly in each handler's target
However, given the reality of ASI, in practice there are two ways to
terminate statements. Then the question becomes, what is more usable,
optionally turning off ASI, or under prior opt-in to Harmony, improving ASI?
I would love to be able to ditch my ; in JS. There are other languages
that
2011/4/18 Bob Nystrom rnyst...@google.com:
The semicolon elision rules from what I've seen are a good bit simpler than
the current insertion ones: If a token that can't end an expression or
statement precedes a newline, eat the newline.
If I understand semicolon elision, then
myLabel:
for
On 4/18/11, Claus Reinke claus.rei...@talk21.com wrote:
The only places where semicolons are ever used in the Node.js package
manager are in the 'for' loops headers and at the *beginning* of the lines
that would be interpreted incorrectly because of the lack of the semicolon
at the end of the
30 matches
Mail list logo
