Re: excluding features from sloppy mode

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

Re: excluding features from sloppy mode

> 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

Re: excluding features from sloppy mode

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,

Re: excluding features from sloppy mode

> 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 invis

Re: excluding features from sloppy mode

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

Re: excluding features from sloppy mode

> 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, li

Re: excluding features from sloppy mode

David Herman wrote: On Dec 28, 2012, at 12:30 PM, Brendan Eich 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 modu

Re: excluding features from sloppy mode

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

Re: barrier dimension, default dimension

David Herman wrote: On Dec 28, 2012, at 12:11 PM, Brendan Eich 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. Since y

Re: excluding features from sloppy mode

On Dec 28, 2012, at 12:30 PM, Brendan Eich 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 modules more:

Re: WebIDL attribute reflection

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 ac

Re: excluding features from sloppy mode

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 func

Re: barrier dimension, default dimension

On Dec 28, 2012, at 12:11 PM, Brendan Eich 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. >> > > Since you mai

Re: barrier dimension, default dimension

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 unreada

Re: Changing [[Prototype]]

Rick Waldron wrote: In the past I've engaged members of the node community about this and general response is: "__ didn't know about the ES5 APIs". ...which is certainly not a reason to include them in any part of the specification, annex or not Right. So the full answer to Andreas and o

Re: WebIDL attribute reflection

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, c

Re: excluding features from sloppy mode

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 o

Re: excluding features from sloppy mode

On Dec 28, 2012, at 12:20 PM, Brendan Eich 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 argument recently,

Re: The 1JS experiment has failed. Let's return to plan A.

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) {

Re: WebIDL attribute reflection

Boris Zbarsky wrote: All that said, I feel like I'm missing context in this discussion. Why do we need to change anything about how WebIDL attributes are reflected? There were good reasons for the current setup, including the fact that it's somewhat widely deployed already (e.g. implemented i

Re: Changing [[Prototype]]

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

Re: excluding features from sloppy mode

David Herman wrote: On Dec 28, 2012, at 3:01 AM, Kevin Smith 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 coarse-grained, but t

Re: WebIDL attribute reflection

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 v

Re: barrier dimension, default dimension

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 Muc

Re: barrier dimension, default dimension

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 considered

Re: excluding features from sloppy mode

On Dec 28, 2012, at 3:01 AM, Kevin Smith 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 coarse-grained, but they can easily be sign

Re: On dropping @names

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

Re: excluding features from sloppy mode

On Dec 26, 2012, at 10:56 PM, Brendan Eich 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 > module

Re: On dropping @names

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 es-discuss@mozil

Re: On dropping @names

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

Re: Changing [[Prototype]]

Andreas Rossberg wrote: On 28 December 2012 11:51, 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

Re: Changing [[Prototype]]

Mariusz Nowak wrote: 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

Re: On dropping @names

On Dec 28, 2012, at 11:47 AM, Andreas Rossberg 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 throughout the

Re: WebIDL attribute reflection

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 proxie

Re: Changing [[Prototype]]

On Dec 28, 2012, at 11:48 AM, Andreas Rossberg 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 ___

Re: Changing [[Prototype]]

On 28 December 2012 19:55, Mark S. Miller 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 sufficiently minor player,

Re: Dynamically changing of loader global

On Dec 26, 2012, at 3:03 PM, David Bruant 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 point out a po

Re: On dropping @names

On 28 December 2012 19:54, David Herman wrote: > On Dec 28, 2012, at 2:29 AM, Andreas Rossberg 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 'cons

barrier dimension, default dimension

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

Re: Changing [[Prototype]]

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 __pro

Re: On dropping @names

On Dec 28, 2012, at 2:29 AM, Andreas Rossberg 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 just > droppe

Re: On dropping @names

On Dec 28, 2012, at 2:11 AM, Andreas Rossberg 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); >> let

Re: `import` and aliasing bindings

On Dec 28, 2012, at 10:31 AM, Kevin Smith 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 > direction of re

Re: `import` and aliasing bindings

> 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

Re: A Variation on ES Modules

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 harmony

Re: `import` and aliasing bindings

> +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

Re: `import` and aliasing bindings

why poorly supported? that logic is easy to reproduce in ES5 modules, isn't it? // a.js var B; function A() {} // runtime each time A.prototype.m = function () { return B ? new B : (B = require('B'), new B); }; // lazily optimized A.prototype.m = function () { B = require('b'); return (A.p

Re: `import` and aliasing bindings

+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 wrote: > On Dec 28, 2012, at 8:32 AM, Domenic Denic

Re: `import` and aliasing bindings

On Dec 28, 2012, at 9:39 AM, Domenic Denicola wrote: > On Dec 28, 2012, at 12:28, "David Herman" 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 va

Re: `import` and aliasing bindings

On Dec 28, 2012, at 12:28, "David Herman" 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 be awesome. Also

Re: `import` and aliasing bindings

On Dec 28, 2012, at 9:16 AM, Domenic Denicola 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 single-export question.

Re: excluding features from sloppy mode

> 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 w

Re: `import` and aliasing bindings

On Dec 28, 2012, at 9:12 AM, Andreas Rossberg 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'll hold off on

Re: excluding features from sloppy mode

On Fri, Dec 28, 2012 at 9:53 AM, Kevin Smith 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 >> without tr

Re: `import` and aliasing bindings

On Dec 28, 2012, at 11:54, "David Herman" wrote: > On Dec 28, 2012, at 8:32 AM, Domenic Denicola > 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. >

Re: `import` and aliasing bindings

On 28 December 2012 17:54, David Herman 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 that I actually

Re: `import` and aliasing bindings

> 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(); > retu

Re: `import` and aliasing bindings

On Dec 28, 2012, at 8:32 AM, Domenic Denicola 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 is a very interesting

Re: `import` and aliasing bindings

On Dec 28, 2012, at 11:19, "Andreas Rossberg" mailto:rossb...@google.com>> wrote: On 28 December 2012 16:20, Domenic Denicola mailto:dome...@domenicdenicola.com>> wrote: Finally, I can't shake the feeling I'm missing something. Why is this aliasing property valuable, given that it's so contradi

Re: `import` and aliasing bindings

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 oth

Re: `import` and aliasing bindings

On 28 December 2012 16:20, Domenic Denicola wrote: > 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 stat

Re: excluding features from sloppy mode

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, du

`import` and aliasing bindings

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; }; }

Re: The 1JS experiment has failed. Let's return to plan A.

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

RE: excluding features from sloppy mode

> 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 wil

Re: excluding features from sloppy mode

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 someho

Re: excluding features from sloppy mode

> 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

Re: Changing [[Prototype]]

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 on

Re: excluding features from sloppy mode

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.

Re: Changing [[Prototype]]

On Dec 28, 2012, at 7:36, "David Bruant" wrote: > Le 28/12/2012 13:32, Anne van Kesteren a écrit : >> On Fri, Dec 28, 2012 at 12:51 PM, 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 __d

Re: excluding features from sloppy mode

On Fri, Dec 28, 2012 at 6:06 AM, 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 modules, > would not apply to them. > Sorry, I should have expanded fur

Re: Changing [[Prototype]]

On 28 December 2012 13:34, Herby Vojčík 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 alternative, mu

Re: Changing [[Prototype]]

Le 28/12/2012 13:32, Anne van Kesteren a écrit : On Fri, Dec 28, 2012 at 12:51 PM, 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. __proto__ is in all browsers What?

Re: Changing [[Prototype]]

Le 28/12/2012 13:32, Anne van Kesteren a écrit : On Fri, Dec 28, 2012 at 12:51 PM, 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. __proto__ is in all browsers What?

Re: Changing [[Prototype]]

Andreas Rossberg wrote: On 28 December 2012 11:51, David Bruant 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 would indicate that

Re: Changing [[Prototype]]

On Fri, Dec 28, 2012 at 12:51 PM, 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. __proto__ is in all browsers, __defineGetter__ is not. -- http://annevankesteren.

Re: Changing [[Prototype]]

Le 28/12/2012 12:51, Andreas Rossberg a écrit : On 28 December 2012 11:51, 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"?

Re: Changing [[Prototype]]

On 28 December 2012 11:51, 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 le

Re: excluding features from sloppy mode

> > 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 es-discuss@mozilla

Re: excluding features from sloppy mode

> 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). Anyt

Re: Changing [[Prototype]]

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 wou

Re: Changing [[Prototype]]

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 t

Re: On dropping @names

On 28 December 2012 11:22, Brendan Eich 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? Apart fr

Re: On dropping @names

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 ___

Re: Changing [[Prototype]]

David Bruant wrote: Le 28/12/2012 10:29, Andreas Rossberg a écrit : On 28 December 2012 05:38, Brendan Eich > 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 f

Re: excluding features from sloppy mode

Brendan Eich wrote: Mark S. Miller wrote: Class is an interesting case though, for three reasons. 1) Its body is not a function body, and so it would be yet more syntax to enable a class to opt into strict mode explicitly. Right. I don't think we've considered this carefully in TC39 yet. 2

Re: On dropping @names

On 28 December 2012 07:10, David Herman wrote: > On Dec 27, 2012, at 2:13 PM, Andreas Rossberg 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 erroneous programs (i.e. where th

Re: Changing [[Prototype]]

Le 28/12/2012 10:29, Andreas Rossberg a écrit : On 28 December 2012 05:38, Brendan Eich > 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 be

WebIDL attribute reflection (was: Dynamically changing of loader global)

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 eith

Re: Changing [[Prototype]]

On 28 December 2012 05:38, Brendan Eich 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 think it makes sense t

Re: Dynamically changing of loader global

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.

Re: Real World Func Decl in Block Scope Breakages

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 be