Re: Real World Func Decl in Block Scope Breakages

Charles McCathie Nevile wrote: On Thu, 27 Dec 2012 00:26:48 +0100, Brendan Eich wrote: Brian Terlson wrote: 20 sites, however, will likely be broken by this change in some way. I am guessing this is the key point. But there is a scope error, and "this" is undefined. It seems you're trying

Re: excluding features from sloppy mode

Mark S. Miller wrote: On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich wrote: IOW, I want more strict extensions too, but implicitly! Again, having to write "use strict"; itself makes for more sloppy code over time, but new syntax can be its own reward for the new semantics. Geez I find this te

whither TDZ for 'let' (was: On dropping @names)

This thread needs a new subject to be a spin-off on the very important topic of to TDZ or not to TDZ 'let'. IMHO you neatly list the risks below. I had swallowed TDZ in the face of these risks. I'm still willing to do so, for Harmony and for greater error catching in practice. I strongly suspe

Re: excluding features from sloppy mode

On Dec 27, 2012, at 8:54 AM, Kevin Smith wrote: > >>> Since any new code will likely be written as a module (even in the >>> near-term, transpiled back to ES5), this would be the ideal scenario. >> >> Which "this" do you mean? modules (in or out of line) implying strict mode >> can target ES

Re: On dropping @names

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 the first version throws, because 'x' is >>> used

Re: On dropping @names

David Herman wrote: ES1 in 1995 "JS" if you please! No "ES" till 1996 November at earliest, really till June 1997. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Changing [[Prototype]]

Andreas Rossberg wrote: On 27 December 2012 18:25, Brendan Eich > wrote: That is, if having it at all, I'd still think it much wiser to ban it to some Appendix. What earthly good would that do? Marketing and psychology (as I said, being importa

Re: Changing [[Prototype]]

On 27 December 2012 18:25, Brendan Eich wrote: > That is, if having it at all, I'd still think it much wiser to ban it to >> some Appendix. >> > > What earthly good would that do? Marketing and psychology (as I said, being important). It would send a clear message that it is just ES adopting so

Re: On dropping @names

On 27 December 2012 23:38, Andreas Rossberg wrote: > I don't feel qualified to talk for Scheme, but all Ocaml I've ever > seen (SML uses more verbose 'let' syntax anyway) formatted the above as > > let sq = x * x in >> print ("sq: " ^ toString sq ^ "\n"); >> >> let y = sq / 2 in >>

Re: On dropping @names

On 27 December 2012 21:23, David Herman wrote: > On Dec 27, 2012, at 1:51 AM, Andreas Rossberg wrote: > > > I think hoisting can mean different things, which kind of makes this > debate a bit confused. > > Yep. Sometimes people mean "the scope extends to a region before the > syntactic position

Re: On dropping @names

On 27 December 2012 21:08, David Herman wrote: > On Dec 27, 2012, at 1:23 AM, Andreas Rossberg wrote: > >> var x; > >> if (...) { x = ... } > >> if (x === undefined) { ... } > >> > >> If you want to use let instead, the === if-condition will throw. You > would instead have to write:

Re: On dropping @names

On Dec 27, 2012, at 1:51 AM, Andreas Rossberg wrote: > I think hoisting can mean different things, which kind of makes this debate a > bit confused. Yep. Sometimes people mean "the scope extends to a region before the syntactic position where the declaration appears," sometimes they mean "the

Re: On dropping @names

On Dec 27, 2012, at 1:23 AM, Andreas Rossberg wrote: >> Let's start with TDZ-RBA. This semantics is *totally untenable* because it >> goes against existing practice. Today, you can create a variable that starts >> out undefined and use that on purpose: > > I think nobody ever proposed going fo

Re: Dynamically changing of loader global

So does anyone know why? Own properties were the obvious choice, so there must have been some reason to choose inherited accessors instead. On Thu, Dec 27, 2012 at 11:32 AM, Brandon Benvie wrote: > It's definitely been my experience that accessors, as found in IE and > Firefox, are much more fidg

Re: Dynamically changing of loader global

It's definitely been my experience that accessors, as found in IE and Firefox, are much more fidgety and error prone than own data properties, as found in WebKit. The fact that it becomes possible to call them on invalid targets and that it's no longer possible for a debugger to simply display own

Re: Dynamically changing of loader global

Le 27/12/2012 20:04, Mark S. Miller a écrit : This is a very good point. Is there any reason other than legacy compat why WebIDL specifies inherited accessors rather than own properties? There is no legacy compat issue. Before WebIDL, the ECMAScript representation of DOM objects was an absurd u

Re: Dynamically changing of loader global

On Wed, Dec 26, 2012 at 3:03 PM, David Bruant wrote: > Le 26/12/2012 23:14, David Herman a écrit : > >> On Dec 24, 2012, at 2:34 PM, David Bruant wrote: >> >>> I've reading the loader API [1] and I was wondering if it was possible to >>> dynamically change the global. I think it is by doing the f

Re: Changing [[Prototype]]

Andreas Rossberg wrote: On 27 December 2012 06:38, David Herman > wrote: On Dec 24, 2012, at 1:48 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote: > It seems ES6 has __proto__ which also allows modifying [[Prototype]] > so presumably this is nothing

Re: Object model reformation?

Andreas Rossberg wrote: On 27 December 2012 05:53, Brendan Eich > wrote: I have a theory: hashes and lookup tables (arrays or vectors) have displaced most other data structures because most of the time, for most programs (horrible generalizations I know),

Re: excluding features from sloppy mode

> Since any new code will likely be written as a module (even in the >> near-term, transpiled back to ES5), this would be the ideal scenario. >> > > Which "this" do you mean? modules (in or out of line) implying strict mode > can target ES5 strict, no problem. "This" meaning all module code (in o

Re: Object model reformation?

On 27 December 2012 05:53, Brendan Eich wrote: > I have a theory: hashes and lookup tables (arrays or vectors) have > displaced most other data structures because most of the time, for most > programs (horrible generalizations I know), you don't need ordered entries, > or other properties that mi

Re: Changing [[Prototype]]

On Thu, Dec 27, 2012 at 6:38 AM, David Herman wrote: > Thank for the heads up. I'll chat with bz to get more of the back story. This > is pretty effing awful. It may in fact be unavoidable but I'd like to make > sure I understand why people feel there's no alternative; otherwise I may > have to

Re: Changing [[Prototype]]

On 27 December 2012 06:38, David Herman wrote: > On Dec 24, 2012, at 1:48 AM, Anne van Kesteren wrote: > > It seems ES6 has __proto__ which also allows modifying [[Prototype]] > > so presumably this is nothing particularly bad, although it is very > > ugly :-( > > It is never safe to assume that

Re: excluding features from sloppy mode

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 pu

Re: Object model reformation?

Good points. I rarely (if ever) miss more powerful collections. I do miss more functionality along the lines of the standard libraries of functional programming languages. And I sometimes miss working with arrays of objects (or maps) like in relational calculus (or, possibly, LINQ). That last on

Re: On dropping @names

On 27 December 2012 05:36, David Herman wrote: > On Dec 26, 2012, at 7:40 PM, Brendan Eich wrote: > > >> Many also believe that hoisting is an excellent feature, not a > weirdness. > > > > For functions, I can defend hoisting, although if I had had more time, I > might have done a let ... in ...

Re: excluding features from sloppy mode

On Thu, Dec 27, 2012 at 12:24 AM, Brendan Eich 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 >>

Re: On dropping @names

On 27 December 2012 01:50, David Herman wrote: > On Dec 11, 2012, at 2:45 AM, Andreas Rossberg wrote: > > The question, then, boils down to what the observation should be: a > > runtime error (aka temporal dead zone) or 'undefined'. Given that > > choice, the former is superior in almost every

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

Le 27/12/2012 02:52, Brandon Benvie a écrit : As an aside, ES itself can't self-host its own builtins in strict mode because of the (two of the very few) semantic differences that exist between strict mode and non-strict mode: non-strict thrower properties (which I've come to consider an annoyi

Re: Changing [[Prototype]]

Le 27/12/2012 06:40, David Herman a écrit : We've given up on the (non-existent) invariant that [[Prototype]] is immutable. That doesn't mean we should set caution to the wind and specify standard libraries that mutate [[Prototype]] links whenever it happens to solve some problem. As you'll see

Re: excluding features from sloppy mode

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