On 16 January 2013 19:33, Brandon Benvie bran...@brandonbenvie.com wrote:
Without using modules as the indicator, how do you know whether code is
intended to be run as ES6 or not? Do let and const count as ES6
(retroactively applying to code using the old non-standard versions, which
are still
On 1 January 2013 07:09, Mark Miller erig...@gmail.com wrote:
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
I'm pretty happy with Kevin's compromise. Here it is again:
(1) No opt-in required for new syntax, except:
(2) No breaking changes to
Without using modules as the indicator, how do you know whether code is
intended to be run as ES6 or not? Do let and const count as ES6
(retroactively applying to code using the old non-standard versions, which
are still currently supported by V8 and Spidermonkey)? Does it apply to
code that
Oliver Hunt wrote:
Note that this isn't a opt-in, this is an attempt to try and
minimise the differences between strict and sloppy modes. My ideal is
that anything that can be unambiguously supported in sloppy mode
should be.
I'm still with you on this.
/be
There's no const in IE, so we are pretty sure we can take the hit of
breaking Mozilla (non-IE branches, also WebKit, maybe Opera) code that
uses const.
/be
Brandon Benvie wrote:
The incompatibilities between let/const as implemented in V8 and
Spidermonkey and how they're specified in ES6 are
On Jan 16, 2013, at 11:26 AM, Brandon Benvie bran...@brandonbenvie.com wrote:
The incompatibilities between let/const as implemented in V8 and Spidermonkey
and how they're specified in ES6 are an additional factor:
* Per iteration loop binding (V8 and Spidermonkey don't do this for
Oliver Hunt wrote:
let isn't really relevant in sloppy mode, unless we decide to take let
over destructuring (which would make me really sad)
You missed the last TC39 meeting, where we agreed (with some misgivings)
to have both, but to break backward compat if any extant code indexes
into
Even 10? If that's the case anything using const is inherently tied to
jsc,v8,moz,opera behaviour.
Presumably the strictest of those _works_, but maybe i'm wrong?
We should probably just enumerate all the differences and see which can be
coalesced and which make sense in sloppy mode.
Obvious
-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Even 10? If that's the case anything using const is inherently tied to
jsc,v8,moz,opera behaviour.
Presumably the strictest of those _works_, but maybe i'm wrong?
We should probably just enumerate all the differences and see
...@mozilla.org] on
behalf of Oliver Hunt [oli...@apple.com]
Sent: Wednesday, January 16, 2013 14:40
To: Brendan Eich
Cc: Mark S. Miller; Mark Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Even 10? If that's the case anything using const is inherently tied
Oliver Hunt wrote:
Even 10? If that's the case anything using const is inherently tied to
jsc,v8,moz,opera behaviour.
Yes, even IE10.
Presumably the strictest of those _works_, but maybe i'm wrong?
Opera equates const and var, last I heard.
/be
Brendan Eich wrote:
Ease of teaching != successfully imparted knowledge at scale. Sorry, but
it's true. People don't use use strict; at top level enough, and
teaching them all will take time. Even then, because of the Law of Least
Effort, it'll be left out.
This is the major objection some
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never seen that in JS. In ML
.
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Saturday, December 29, 2012 7:10 PM
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote
(b) ES6 sloppy mode cannot have let.
That's overstated, and as such it contradicts the tenuous consensus of the
last TC39 meeting: to reserve 'let' contextually in sloppy mode and
evangelize any let [x] = y code out there already (which we've yet to find
-- 'let' is used as an identifier,
Kevin Smith wrote:
(b) ES6 sloppy mode cannot have let.
That's overstated, and as such it contradicts the tenuous
consensus of the last TC39 meeting: to reserve 'let' contextually
in sloppy mode and evangelize any let [x] = y code out there
already (which we've yet to
The only motivation for me is in attempting to get rid of there even being
two modes. I don't really care if it was strict or not strict, just that
there's only one of them. Obviously the horse left the barn for ES5 long
ago, but the desire to collapse down to one mode in as much code as
possible
Brandon Benvie wrote:
The only motivation for me is in attempting to get rid of there even
being two modes. I don't really care if it was strict or not strict,
just that there's only one of them. Obviously the horse left the barn
for ES5 long ago, but the desire to collapse down to one mode in
And again, ES5 failed to reserve 'module' in strict mode, and ES1-3 never
reserved 'module', so ES6 must make 'module' only contextually reserved. We
are already in either it's an identifier, or it isn't default. If we can
do it for 'module', why not for 'let'?
Easy: module is still a first
Kevin Smith wrote:
And again, ES5 failed to reserve 'module' in strict mode, and
ES1-3 never reserved 'module', so ES6 must make 'module' only
contextually reserved. We are already in either it's an
identifier, or it isn't default. If we can do it for 'module',
why not for
The only place 'let' is contextually reserved in the quasi-consensus from
the last TC39 meeting is at the start of a statement, when followed by an
identifier, '{', or '['.
Right - which makes let a second class identifier (sorry,
made-up-term), since it can't be used in let[x] = y. I
shed
On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
And again, ES5 failed to reserve 'module' in strict mode, and
ES1-3 never reserved 'module', so ES6 must make 'module' only
contextually reserved. We are already in either it's an
Kevin Smith wrote:
The only place 'let' is contextually reserved in the
quasi-consensus from the last TC39 meeting is at the start of a
statement, when followed by an identifier, '{', or '['.
Right - which makes let a second class identifier (sorry,
made-up-term), since it can't
Mark S. Miller wrote:
Thanks for clarifying the primacy of the rule. It was not clear, and it
does not match what Dave proposed that Mark reconfirmed as 1JS. Although
Dave left some wiggle room in his first post, I want to say that my attempts
to make all new body-forms strict don't fit
Domenic Denicola wrote:
What I realized is thattoday that is exactly the sort of code you wrap in an
IIFE, i.e. (function () { }());.
Script concatenation does not wrap an IIFE around the whole
concatenation, and cannot in general.
/be
___
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich
bren...@mozilla.comhttps://mail.google.com/mail/?view=cmfs=1tf=1to=bren...@mozilla.com
wrote:
Mark S. Miller wrote:
Thanks for clarifying the primacy of the rule. It was not clear, and it
does not match what Dave proposed that Mark reconfirmed
Mark Miller wrote:
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich bren...@mozilla.com
https://mail.google.com/mail/?view=cmfs=1tf=1to=bren...@mozilla.com
wrote:
Mark S. Miller wrote:
As I understood Dave's clarification, 1JS is orthogonal to our
decisions about how many
On 29 December 2012 22:06, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
ES6+ will stay much longer (at least that's what we are working for).
Consequently, what should take precedence are the expectations and
needs of _future_ users of ES. Those who will come to ES6+ without
On 29 December 2012 22:11, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
On 29 December 2012 14:51, Axel Rauschmayera...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle
things?
Ideally? Backing out of the whole 1JS marketing
On 30 December 2012 02:31, Mark S. Miller erig...@google.com wrote:
If duplicate formals are the only such case, then I agree that the
fear of micro-mode is a non-issue. Do we have an accurate record of
the scoping of default value expressions? How about the interaction of
head scope and top
Ease of teaching != successfully imparted knowledge at scale. Sorry, but
it's true. People don't use use strict; at top level enough, and
teaching them all will take time. Even then, because of the Law of Least
Effort, it'll be left out.
This is the major objection some of us keep raising,
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Sunday, December 30, 2012 00:06
by yoking ES6 feature adoption to strict mode adoption, you
multiply risks and reduce ES6 adoption.
I'd like to lend a
Andreas Rossberg wrote:
On 29 December 2012 22:06, Brendan Eichbren...@mozilla.com wrote:
Andreas Rossberg wrote:
ES6+ will stay much longer (at least that's what we are working for).
Consequently, what should take precedence are the expectations and
needs of _future_ users of ES. Those who
Andreas Rossberg wrote:
There
also is the sloppy-mode-arguments-object vs destructuring issue.
Thanks, I forgot that one. It's a good point, since one cannot
statically catch all 'arguments' uses in general.
Years ago we implemented destructuring parameters in JS1.7-1.8, without
I agree. To me it comes down to cognitive load. A good way of measuring that is
whether one can state a simple rule. For Andreas’ approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module around it.”
- Pro 1JS: You can use new stuff everywhere.
- Contra 1JS: You
, 2012 22:10
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never seen
On 30 December 2012 11:58, Brendan Eich bren...@mozilla.com wrote:
Two separate things:
1. All new syntax with code bodies makes strict-by-fiat code bodies.
2. New parameter forms restrict duplicate parameters.
Neither entails various features locally chang[ing] the semantics of
unrelated
Axel Rauschmayer wrote:
It would actually be nice to have that as a feature: If the variable
name is `_` then it can be used multiple times. It’s a nice,
self-descriptive way of saying that you don’t care about a parameter value.
It is a valid identifier, one may actually use it. Better
On 30 December 2012 12:50, Axel Rauschmayer a...@rauschma.de wrote:
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
That underscore
On Sun, Dec 30, 2012 at 3:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
I agree. To me it comes down to cognitive load. A good way of measuring that
is whether one can state a simple rule. For Andreas’ approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module
On Sunday, December 30, 2012, Mark S. Miller wrote:
In the short term, while people are making the transition, the rule
would be stated as above “If you want the new stuff, turn on strict
mode or wrap a module around it.” Later, once ES6 is everywhere, it
would instead be stated as Turn on
Axel Rauschmayer wrote:
I agree. To me it comes down to cognitive load. A good way of
measuring that is whether one can state a simple rule. For Andreas’
approach, it would be:
“If you want the new stuff, turn on strict mode or wrap a module
around it.”
That is different from what TC39 has
Brandon Benvie wrote:
On Sunday, December 30, 2012, Mark S. Miller wrote:
In the short term, while people are making the transition, the rule
would be stated as above “If you want the new stuff, turn on strict
mode or wrap a module around it.” Later, once ES6 is everywhere, it
- Pro 1JS: You can use new stuff everywhere.
- Contra 1JS: You can’t use all of the new stuff. There are tricky
exceptions and rules.
Check me: I think the only exceptions that we have found are let and
function-in-block. At the last TC39 meeting, we resolved to try reserving let
Axel Rauschmayer wrote:
I made a list of the 10 biggest JS pitfalls and most of them will be
gone under ES6. Much less to worry about, much easier to learn.
Could you share your 10-biggest list?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
That underscore wildcard is the exact syntax used in functional
languages, and very
Another thought: What will JavaScript code look like once 99% of browsers in
use support ES6? Will we have a language with coherent semantics and a
simple structure? That is: is there a way to drop some of the trickiness,
long term? And which of the approaches gets us there?
In the short term,
Claus Reinke wrote:
// suggestion
Perhaps there is a way to make the automated upgrade
problem solvable/cheap? Instead of ES6+ supporting sloppy
mode and strict mode and mixtures of new features with
sloppy mode indefinetly, how about turning the situation
on its head:
- ES6 engines default to
This is a bit long - bear with me...
First, let me make one more argument as to why new syntax, just use it
won't work:
(a) In ES6, let is the preferred way to declare variables. Let's not be
relativistic to the point of goo here. Block-scoped variables are
better. As such, let is of central
Kevin Smith wrote:
This is a bit long - bear with me...
First, let me make one more argument as to why new syntax, just use
it won't work:
(a) In ES6, let is the preferred way to declare variables. Let's
not be relativistic to the point of goo here. Block-scoped variables
are better. As
I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me reiterate one particular observation, which is that IMHO much of
the discussion (and decision making) around 1JS, modes, and opt-ins is
just mistargeted.
I’m sympathetic to both sides of this argument. How would you handle things?
On Dec 29, 2012, at 14:47 , Andreas Rossberg rossb...@google.com wrote:
I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me
On 29 December 2012 14:51, Axel Rauschmayer a...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle things?
Ideally? Backing out of the whole 1JS marketing maneuver? In the long
run, I see it as more harmful than helpful, as it inevitably leads to
complexity
Andreas Rossberg wrote:
I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me reiterate one particular observation, which is that IMHO much of
the discussion (and decision making) around 1JS, modes, and opt-ins
Andreas Rossberg wrote:
On 29 December 2012 14:51, Axel Rauschmayera...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle things?
Ideally? Backing out of the whole 1JS marketing maneuver?
It's not just marketing surface, but lack of version= substance.
Brendan Eich wrote:
subtle mode mixtures,
I don't buy this one either. We have ES5 sloppy and strict, they mix
only statically, with well-defined rules based on use strict; (which
is not a readability trump card to throw, as discussed).
Any dynamic mixing is at the function call boundary.
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me reiterate one particular observation, which is that IMHO
Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eichbren...@mozilla.com wrote:
Who ever proposed that? It seems a misunderstanding. No one is saying that,
e.g., destructuring formal parameters, or a rest parameter, should flip the
containing function into strict mode. Banning
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eichbren...@mozilla.com wrote:
Who ever proposed that? It seems a misunderstanding. No one is saying
that,
e.g., destructuring formal parameters, or a
I gotta say, I'm in agreement with Mark (and even Andreas) here. 1JS,
under all modes just isn't going to work (let[x] = y proves that). And
keeping track of what's allowed under which mode (and why) could get
complicated and difficult to explain.
But what about this?
One JS,
Under strict
Put everything new in ES6 as implicit opt-in for strict mode? It certainly
is the simplest of all options, both for implementors and users. It also
removes the big enough carrot problem. Any individual feature may not be
enough of a carrot to sway a user, and taken as one by one choice, might
Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eichbren...@mozilla.com wrote:
Mark S. Miller wrote:
2) Make a micro-mode, adding yet additional mode switching in order to
supposedly avoid the complexity of dealing with one mode switch.
No, you are using micro-mode as an
On Sat, Dec 29, 2012 at 5:16 PM, Brendan Eich bren...@mozilla.com wrote:
I'm prepared to give up on the ban of duplicate formals when destructuring
parameters are present, if that will get rid of your objection to
micro-modes. I don't recall anything else like this case. We arrived at it
@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eichbren...@mozilla.com wrote:
Mark S. Miller wrote:
2) Make a micro-mode, adding yet additional mode switching in order to
supposedly avoid the complexity
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never seen that in JS. In ML, sure.
Have you any links to cite?
/be
___
es-discuss mailing list
The more I think about this, the more convinced I get that all new syntax
and breaking changes (where possible) should be strict-mode only. In
retrospect, `let[x] = y;` changed everything. Here's why I think 1JS
under strict is the best solution:
- How exactly would one teach that classes,
Kevin Smith wrote:
The more I think about this, the more convinced I get that all new
syntax and breaking changes (where possible) should be strict-mode
only. In retrospect, `let[x] = y;` changed everything. Here's why I
think 1JS under strict is the best solution:
- How exactly would one
Kevin Smith wrote:
The more I think about this, the more convinced I get that all new
syntax and breaking changes (where possible) should be strict-mode only
...
1) All new syntax and breaking changes (where possible) are
strict-mode only.
2) Modules and only modules are implicitly strict.
29, 2012 22:10
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Brendan Eich
Sent: Sunday, December 30, 2012 00:06
by yoking ES6 feature adoption to strict mode adoption, you multiply risks
and reduce ES6 adoption.
I'd like to lend a little bit of defense to
Ease of teaching != successfully imparted knowledge at scale. Sorry, but
it's true. People don't use use strict; at top level enough, and teaching
them all will take time. Even then, because of the Law of Least Effort,
it'll be left out.
This is the major objection some of us keep raising,
1) All new syntax and breaking changes (where possible) are strict-mode
only.
2) Modules and only modules are implicitly strict.
(2) is not what (1) says, ignoring the mysterious (where possible)
loophole.
You're really sharp! Notice that I didn't specify in or out-of-line
modules
I believe the only major factors in usage uptake for ES6 will be in the
ever present need for backwards compatibility, and educating developers on
what new tools exist. Imdo not believe having a use strict gatekeeper at
the front of the ES6 bonanza would not be a motivating factor in turning
So I don't see the argument against implicit strict as overriding.
The main argument against implicit strict, peppered across new syntax, is
increased complexity for little gain. In other words, bloat. If you want
implicit strict, then do it for module bodies only (in or out-of-line).
What about node code?
Well, node modules are not ES6 modules. They are functions with an
implicit head and braces. So implicit strict mode, applied to ES6 modules,
would not apply to them.
{ Kevin }
___
es-discuss mailing list
On Fri, Dec 28, 2012 at 6:06 AM, Kevin Smith khs4...@gmail.com wrote:
What about node code?
Well, node modules are not ES6 modules. They are functions with an
implicit head and braces. So implicit strict mode, applied to ES6 modules,
would not apply to them.
Sorry, I should have
On 12/27/12 at 11:36 PM, bren...@mozilla.com (Brendan Eich) wrote:
To find the governing use strict; in a large program or (real
bugs bit ES5 here) concatenation is not easy.
I would want syntax coloring here. Perhaps a light blue
background for strict mode and a light pink one for sloppy.
Sorry, I should have expanded further - that was my point. Node is a case
where I can see classes being used without modules. I imagine native class
support will hit v8 soon enough, and I could see people start using them
without trying to switch to ES6 modules.
Ah - true. They can put a
Kevin Smith wrote:
What about node code?
Well, node modules are not ES6 modules. They are functions with an
implicit head and braces. So implicit strict mode, applied to ES6
That implicit head and braces are in the library, though; so if node
wanted (and it would be possible
Ah - true. They can put a use strict at the top if they want that.
It’s also possible that Node.js will just enable strict mode by default (as
soon as it’s faster than the non-strict mode, which should happen soon); when
they will do so, it will mean that using the non-strict mode will
That implicit head and braces are in the library, though; so if node wanted
(and it would be possible somehow), it could replace it with module. Still
don't know if exporting / reentrant require could be handled without much
fuss.
Possible, but not really clean or (I think) satisfactory, due
On Fri, Dec 28, 2012 at 9:53 AM, Kevin Smith khs4...@gmail.com wrote:
Sorry, I should have expanded further - that was my point. Node is a case
where I can see classes being used without modules. I imagine native class
support will hit v8 soon enough, and I could see people start using them
I guess we'll see soon enough, but I think there's still going to be a big
battle between ES6 modules and node modules and amd/requireJS. Any early
adopter types have already probably invested in something, and because the
porting isn't always straightforward, I think many will stick with what
On Dec 26, 2012, at 10:56 PM, Brendan Eich bren...@mozilla.com wrote:
It does not even contain the word strict. IIRC (and I asked about this at
the last TC39 meeting and got verbal confirmation), the idea of module {...}
implying strict mode was latent, or intended. I'm not sure about out of
David Herman wrote:
On Dec 28, 2012, at 3:01 AM, Kevin Smithkhs4...@gmail.com wrote:
I'm tellin' ya, no one's going to write any significant non-module code. : )
+9001 (to quote rwaldron)
We should hold the line against any implicit opt-in beyond modules. Mark argues
that classes are
On Dec 28, 2012, at 12:20 PM, Brendan Eich bren...@mozilla.com wrote:
I get nervous when speculations about future adoption ratios or incentives
for developers are made without enough data or table-stakes ante'ing (bolded
tripled *biggest* doesn't count as money!).
OK, I've made that same
David Herman wrote:
OK, I've made that same argument recently, I'll take it. I guess what I can
retain of that argument is that*if* modules succeed, then the implicit opt-in
will have bought us little.
That I agree with (already).
But even if*not*, it's not worth proliferating the number
So to speculate, what are the costs and benefits? Earlier in this thread I
said a cost of putting things in strict mode is in increasing the semantic
gap between otherwise identical code (besides the pragma), and the cost of
not doing so it in any compatibility constraints (such as block scope
On Dec 28, 2012, at 12:30 PM, Brendan Eich bren...@mozilla.com wrote:
But even if*not*, it's not worth proliferating the number of cases that are
implicitly strict.
To answer that, you have to speculate on costs and benefits of strict mode
for classes outside of modules, not talk about
Brandon Benvie wrote:
So I don't see what costs are associated with making new function
forms implicitly strict. In fact, I see the reverse: by allowing them
to have two modes, you *create* that very cost same cost. If these new
forms only have one mode then they will be *simpler* than regular
David Herman wrote:
On Dec 28, 2012, at 12:30 PM, Brendan Eichbren...@mozilla.com wrote:
But even if*not*, it's not worth proliferating the number of cases that are
implicitly strict.
To answer that, you have to speculate on costs and benefits of strict mode for
classes outside of modules,
The question really is, why have sloppy-mode classes at all? Who wants or
needs them?
Well, no one, really. But we shouldn't want big invisible switches or any
new pragma-haunts either.
You've said that my predictions are wildly optimistic, and I'm going to
have to push back.
Let me, like
Kevin Smith wrote:
The question really is, why have sloppy-mode classes at all? Who
wants or needs them?
Well, no one, really. But we shouldn't want big invisible switches or
any new pragma-haunts either.
There's no invisible switch. You are assuming something not axiomatic:
that
There's no invisible switch. You are assuming something not axiomatic:
that new syntax head-forms other than module must inherit sloppy from outer
code. That does not follow without more argumentation.
I guess I'm saying that anything other than inheritance, without the
pragma, is an
Kevin Smith wrote:
There's no invisible switch. You are assuming something not
axiomatic: that new syntax head-forms other than module must
inherit sloppy from outer code. That does not follow without more
argumentation.
I guess I'm saying that anything other than inheritance,
1. Except for module.
Right.
2. Non-locality of use strict in the medium-to-large makes for an
effectively invisible, or at least hard to see as in effect, switch.
Mmmm.. maybe.
So are you in favor of class body as strict by default?
You mean as always strict? I wasn't when I wrote
Add me to the list of people who are overjoyed when this AMD vs. CJS/Node.js
travesty is over. That alone is a good answer if people ask: “What can ES6
modules do that current module systems can’t” – it will (most probably) be a
common standard.
So are you in favor of class body as strict by
Kevin Smith wrote:
It does not even contain the word strict. IIRC (and I asked
about this at the last TC39 meeting and got verbal confirmation),
the idea of module {...} implying strict mode was latent, or
intended. I'm not sure about out of line modules.
At this point,
On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich bren...@mozilla.com wrote:
Kevin Smith wrote:
It does not even contain the word strict. IIRC (and I asked
about this at the last TC39 meeting and got verbal confirmation),
the idea of module {...} implying strict mode was latent, or
Le 27/12/2012 06:32, Brendan Eich a écrit :
Mark S. Miller wrote:
Superstition aside, and once pre-ES5 browsers are not significant, the
only purpose of sloppy mode is for old code that must be kept running
without active maintenance.
That is a teleological statement -- you're talking about
1 - 100 of 123 matches
Mail list logo
