Brendan Eich wrote:
What is the proposed change?
ES6 proposes that f-i-b always bind bar in the nearest enclosing
curly-braced block, hoisted in the manner of function in JS today but
to block scope, not function or program scope, so that the function
can be used in expressions evaluated
The trade-off is not between own data properties and shared
prototype-homed accessors.
Rather, it is between own and inherited accessors.
In either case, one needs per-instance state, often stored in a
peer-to-JS C++ DOM native data structure that must exist whether there'
s a JS reflection.
On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads, or else
people read and think less of the spec on that account.
The fewer read about it the better, no? :)
Why would people think less about the spec?
I
Le 28/12/2012 09:23, Brendan Eich a écrit :
The trade-off is not between own data properties and shared
prototype-homed accessors.
Rather, it is between own and inherited accessors.
True. The reason is that WebIDL attributes have types that need to be
enforced [1] among other things.
In
Le 28/12/2012 10:29, Andreas Rossberg a écrit :
On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads,
or else people read and think less of the spec on that account.
The fewer
On 28 December 2012 07:10, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 2:13 PM, Andreas Rossberg rossb...@google.com wrote:
It's true that with TDZ, there is a difference between the two forms
above, but that is irrelevant, because that difference can only be observed
for
Andreas Rossberg wrote:
As for TDZ precedent, ES6 will have plenty of precedent of other
lexical declaration forms that uniformly have TDZ and would not allow
an example like the above.
Can these plenty be enumerated? Apart from const, which ones have TDZs?
/be
On 28 December 2012 11:22, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
As for TDZ precedent, ES6 will have plenty of precedent of other
lexical declaration forms that uniformly have TDZ and would not allow an
example like the above.
Can these plenty be enumerated?
Brendan Eich-3 wrote:
In a more serious vein, we are at cross purposes with reality. Mutable
__proto__ just *is*. It is a de-facto standard.
(...)
Self had writable parent slots. One can disagree with the design
decision, but it's not unique to JS or uniquely evil.
I'm totally
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It would indicate that it's part of the standard, but is
a scar from history rather than a legit feature.
An intro would explain what this is all about.
It
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 28 December 2012 11:51, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto standards?
It would indicate that it's part of the standard, but is a scar from
history rather than a
Le 28/12/2012 12:51, Andreas Rossberg a écrit :
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in all browsers, __defineGetter__ is not.
--
Andreas Rossberg wrote:
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to include __proto__ but not __defineGetter__ and friends.
__proto__ is in
On 28 December 2012 13:34, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
That's a good point, actually. I, for one, do not understand the
criteria by which we chose to include __proto__ but not __defineGetter__
and friends.
__defineGetter__ and friends have sane
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 Dec 28, 2012, at 7:36, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com
wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to
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.
What herby said is the reason. There's no compatibility burden for either
those or __proto__ because no version of IE implements either. However
__proto__ still has no alternative, while the accessor functions are fully
replaced by ES5 features.
The only code you'll find in the wild that relies
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
I ave to recant on this after having doing some research (and actually
making it work). The original reason about ThisMode may still be true but
I'm less sure. It was basically about being unable to identify the correct
global `this` in strict mode since its not automatically provided for you,
and
Now that I have fully digested Andreas's points from the earlier thread on
modules [1], I am a bit concerned about the implications of `import`
introducing aliasing bindings. To recap, the situation is:
module foo {
export let state = 5;
export function modifyState() {
state = 10;
};
}
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 28 December 2012 16:20, Domenic Denicola dome...@domenicdenicola.comwrote:
Now that I have fully digested Andreas's points from the earlier thread
on modules [1], I am a bit concerned about the implications of `import`
introducing aliasing bindings. To recap, the situation is:
module foo
module foo {
export let state = 5;
export function modifyState() {
state = 10;
};
}
import { state, modifyState } from foo;
assert(state === 5);
modifyState();
assert(state === 10);
That's it.
This is, to me as an ES5 programmer, very weird. There is *no other
situation in
On Dec 28, 2012, at 11:19, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 28 December 2012 16:20, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Finally, I can't shake the feeling I'm missing something. Why is this aliasing
On Dec 28, 2012, at 8:32 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Dave and Sam may have a different answer, but I'd answer that the aliasing
semantics follows from a module system's role as (among other things) a name
spacing mechanism.
This idea of modules as namespaces
So I fully agree with all of Andreas's points. Another one is that I've
been thinking we should add getter/setter exports to make it possible to
create lazily initialized exports:
let cell;
export get foo() {
if (!cell)
cell = initialize();
return
On 28 December 2012 17:54, David Herman dher...@mozilla.com wrote:
Another one is that I've been thinking we should add getter/setter exports
to make it possible to create lazily initialized exports:
We haven't had the opportunity to discuss that one, but now that you
mention it, I should say
On Dec 28, 2012, at 11:54, David Herman dher...@mozilla.com wrote:
On Dec 28, 2012, at 8:32 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Dave and Sam may have a different answer, but I'd answer that the aliasing
semantics follows from a module system's role as (among other
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
On Dec 28, 2012, at 9:12 AM, Andreas Rossberg rossb...@google.com wrote:
We haven't had the opportunity to discuss that one, but now that you mention
it, I should say that I actually think exports as accessors are a no-go.
It's just a thought, and I can see already that it's controversial, so
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 28, 2012, at 9:16 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
The aliasing isn't observable for immutable bindings, only for mutable ones.
In my experience, all of the module exports I've seen from NPM modules I've
used were immutable.
This is amusingly tied to the
On Dec 28, 2012, at 12:28, David Herman dher...@mozilla.com wrote:
Another example where this could come up is initialization. Since imports
tend to be at the beginning of a module, you could end up reading the value
of a not-yet-initialized variable too soon.
A code example of this would
On Dec 28, 2012, at 9:39 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
On Dec 28, 2012, at 12:28, David Herman dher...@mozilla.com wrote:
Another example where this could come up is initialization. Since imports
tend to be at the beginning of a module, you could end up reading
+1 for adding getter/setter exports to make it possible to create lazily
initialized exports. This could be very useful for frameworks to keep footprint
lower without causing unintuitive designs.
Benoit
On Dec 28, 2012, at 8:54, David Herman dher...@mozilla.com wrote:
On Dec 28, 2012, at
+1 for adding getter/setter exports to make it possible to create lazily
initialized exports. This could be very useful for frameworks to keep
footprint lower without causing unintuitive designs.
No - we need to keep features out of the module system. Abstractions
should be created with the
Just to finalize this thread, I updated the gist based on comments from
Andreas:
https://gist.github.com/4382710
It includes syntax for proper inline modules, and an extension syntax for
pre-loading (aka concatenating). It also brings the syntax for module
aliasing closer to the previous
However, I agree that the destructuring syntax for module imports may not
be the clearest choice in terms of raising the right expectations. (As we
have discovered already, it has other issues, namely people confusing the
direction of renaming.) Maybe it is a bit too clever, and considering
On Dec 28, 2012, at 10:31 AM, Kevin Smith khs4...@gmail.com wrote:
However, I agree that the destructuring syntax for module imports may not be
the clearest choice in terms of raising the right expectations. (As we have
discovered already, it has other issues, namely people confusing the
On Dec 28, 2012, at 2:11 AM, Andreas Rossberg rossb...@google.com wrote:
That doesn't prove that it was a *bug*. That's a question about the
programmer's intention. In fact, I don't think you can. For example, I
mentioned let-binding at the bottom:
{
console.log(x);
On Dec 28, 2012, at 2:29 AM, Andreas Rossberg rossb...@google.com wrote:
Can these plenty be enumerated? Apart from const, which ones have TDZs?
All declarations whose initialization cannot be hoisted. My understanding is
that that would be 'const', 'class' and 'private', although we have
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a sufficiently minor player, that some cross-mobile-platform code
assumes mutable
Andreas pointed out [1] that the question of defaulting to undefined vs
uninitialized is orthogonal to the question of read-barrier vs read-write
barrier:
Even with TDZ-RBA you can have that meaning for let x (and that semantics
would be closest to 'var'). What TDZ-RBA gives you, then, is
On Dec 26, 2012, at 3:03 PM, David Bruant bruan...@gmail.com wrote:
The initial value. We can look into what it would mean to make it
modifiable, but we'd probably not make that the API; we'd probably just have
a setter.
Good point.
[Adding MarkM into the mix for this part]
I wish to
On 28 December 2012 19:55, Mark S. Miller erig...@google.com wrote:
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a
On Dec 28, 2012, at 11:48 AM, Andreas Rossberg rossb...@google.com wrote:
All understood, but what's the difference to __defineGetter__?
That MS does not appear to feel pressure to implement __defineGetter__ but it
does feel pressure to implement __proto__.
Dave
David Bruant wrote:
Pre-WebIDL DOM bindings cheat by using native code to run on every
set and even get, without the own data property reflecting as an
accessor. That seems worse than what we have settled on with
prototype-homed inherited accessors, no?
I'm not 100% sure. In a world with
On Dec 28, 2012, at 11:47 AM, Andreas Rossberg rossb...@google.com wrote:
We can identify two classes of lexical declarations:
1. Those where initialization can be performed at the start of the scope
(which is what I meant by hoisted above), and the bound variable can safely
be accessed
Andreas Rossberg wrote:
On 28 December 2012 11:51, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto
standards? It
Andreas Rossberg wrote:
1. Those where initialization can be performed at the start of the
scope (which is what I meant by hoisted above),
The h-word will die hard. I think most people use it to mean this, i.e.,
function hoisting. With var context it means binding but not
initialization
Andreas Rossberg wrote:
For the second (let, const, class, private -- although TBH, I forgot
the reason why 'class' is in this group),
To future-proof against class static syntax that can be effectful.
/be
___
es-discuss mailing list
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:
For the first group (function, module), there is no problem. For the second
(let, const, class, private -- although TBH, I forgot the reason why 'class' is in
this group), we have temporal dead zone, where accessing a variable before its
initialization is an error.
The
David Herman wrote:
Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option? The
bug that motivates all the arguments you've made is read-before-initialization,
not write-before-initialization.
Since you mailed the list I will jump in before Andreas answers. TC39
Argh, why must mailman archive + copy/paste result in unreadably long
lines. Here's the citation again (from
https://mail.mozilla.org/pipermail/es-discuss/2011-August/016188.html):
178 nor Normal All allen at wirfs-brock.com CONF --- Must settle scoping
details for block-scoped bindings
On 12/28/12 11:52 AM, Brendan Eich wrote:
Sure, but should all those DOM objects whose pre-WebIDL browser-specific
bindings used magic data properties have to become proxies?
God, I hope not.
Has anyone checked whether doing so is (a) compatible; (b) performant?
It's not performant. It's
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 Friday, December 28, 2012, David Bruant wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto standards?
It would indicate that it's part of the standard, but is a scar from
history rather than a legit feature.
To elaborate on the ThisMode scenario, take the following example (also
available at https://gist.github.com/4401538):
var value = 10;
module X {
// implicit use strict
var value = 20;
export class Builtin {
constructor(){
if (this == null) {
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
On 12/28/12 12:24 PM, Brendan Eich wrote:
David was questioning the new status quo, which is fine -- we benefit
from being skeptical of our theories, as Feynman recommended. He was
motivated by the extra complexity of ES5 accessors, which can be
reflected on, extracted as get and set functions,
Just to be super-clear, since citing in mail (compose and read-time) is
hard: everything after Here's the citation again (...): is cited from
the July 2011 meeting notes followup post I made in August 2011.
/be
Brendan Eich wrote:
Argh, why must mailman archive + copy/paste result in
On Dec 28, 2012, at 12:11 PM, Brendan Eich bren...@mozilla.com wrote:
David Herman wrote:
Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option?
The bug that motivates all the arguments you've made is
read-before-initialization, not write-before-initialization.
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 12/28/12 12:31 PM, Boris Zbarsky wrote:
When we have gets through a proxy down in the 20-30 cycle range on
modern hardware, I'm happy to talk about proxies performance-wise. ;)
One other note. I'm somewhat sympathetic to the argument that the spec
could describe things as proxies while
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
David Herman wrote:
On Dec 28, 2012, at 12:11 PM, Brendan Eichbren...@mozilla.com wrote:
David Herman wrote:
Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option? The
bug that motivates all the arguments you've made is read-before-initialization,
not
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
84 matches
Mail list logo
