Re: excluding features from sloppy mode

Mark Miller wrote: On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich > wrote: Mark S. Miller wrote: As I understood Dave's clarification, 1JS is orthogonal to our decisions about how many of the new featu

Re: excluding features from sloppy mode

On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=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 as "1

Re: excluding features from sloppy mode

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 ___ es-dis

Re: excluding features from sloppy mode

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

Re: excluding features from sloppy mode

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

Re: excluding features from sloppy mode

On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich 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 >> identifie

Re: excluding features from sloppy mode

> 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".

Solving the "how do I tell whether I have an HTML element?" (or image element, or whatever) problem

Note: es-discuss is bcced, but please reply to public-script-coord. The fact that instanceof for "standard classes" is completely broken when multiple globals are involved has come up yet again, as Gecko converts to WebIDL bindings. The reason for that is that currently in Gecko's DOM binding

Re: excluding features from sloppy mode

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

Re: excluding features from sloppy mode

> 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

Re: 10 biggest JS pitfalls

Yes, see the thread starting at https://mail.mozilla.org/pipermail/es-discuss/2012-December/027419.html if you haven't. The SpiderMonkey implementation was "first", for what it's worth -- from 1997. ES3 did not specify any function in block production, of course. The intersection with IE semant

Re: 10 biggest JS pitfalls

I've just discovered that someone is fallen in the following pit: Change of the semantic of function declarations in Firefox when included in block (spoiler: hoisting issue). (Not standard ES for sure, but definitely JS.) Enjoy: http://statichtml.com/2011/spidermonkey-function-hoisting.html —Clau

Re: excluding features from sloppy mode

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

Re: Better property behavior

Allen Wirfs-Brock wrote: On Dec 31, 2012, at 10:14 AM, Axel Rauschmayer wrote: Currently making a typo in property names can be fatal in two ways: When reading a property, things fail silently and you get back `undefined`. When setting a property, you accidentally create a new property. A sa

Re: Better property behavior

On Dec 31, 2012, at 10:14 AM, Axel Rauschmayer wrote: > Currently making a typo in property names can be fatal in two ways: When > reading a property, things fail silently and you get back `undefined`. When > setting a property, you accidentally create a new property. > > A safer behavior woul

Re: excluding features from sloppy mode

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 i

Re: Symbol toString behavior (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

On Dec 31, 2012, at 4:38 AM, Tom Van Cutsem wrote: > 2012/12/31 Allen Wirfs-Brock > responses for chapter 8, except for 8.5 which will get its own message. > > On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote: > > 8.4.4 Exotic Symbol Objects > > Typo: "A{n} Symbol object is an exotic object…"

Re: excluding features from sloppy mode

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

Re: [[SetInheritance]] (was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

On Dec 31, 2012, at 7:28 AM, Brandon Benvie wrote: > > On Monday, December 31, 2012, Tom Van Cutsem wrote: > That said, I think this issue is orthogonal to our choice of whether or not > to expose "setPrototypeOf" as part of the MOP. Even if we do expose it, any > sandbox that wants to take aw

Re: 10 biggest JS pitfalls

Jorge Chamorro wrote: On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote: I'm surprised not to see Automatic Semicolon Insertion in the list. Yes I would ditch ASI altogether if only to force the javascrhipsters to put back each and every semicolon where it belongs: they are *delimiters*.

Re: 10 biggest JS pitfalls

I don't think ASI _per se_ is the problem. Rather, the restricted productions bite people: function foo() { return very + long + expression() + goes + here; } and of course, the expectation of ASI where there's no error to correct: a = b (function () { ... // lots of line

Re: Why does legacy content break when making array-likes real arrays?

The work so far in the spec on enabling subclassing has been awesome and I look forward to seeing this! On Mon, Dec 31, 2012 at 1:52 PM, Allen Wirfs-Brock wrote: > > In support of Array subclassing, I have a tweak to concat that allows > properly formed subclasses of Array to use concat and produ

Re: Why does legacy content break when making array-likes real arrays?

On Dec 31, 2012, at 10:39 AM, Brandon Benvie wrote: > True, concat specifically needs to be changed. But it is the only Array > method that does that check (the only other internal checks for brand > BuiltinArray are in apply and isArray I think). In support of Array subclassing, I have a twea

Re: WebIDL attribute reflection

On 12/31/12 2:24 AM, David Bruant wrote: Polyfillability is an interesting criteria. Is Object.getOwnPropertyDescriptor polyfillability important? Would a good [[Get]]+[[Set]] polyfill be enough? By that I mean that as long as the [[Get]]+[[Set]] behavior is good, maybe polyfilling a property by

Re: Why does legacy content break when making array-likes real arrays?

True, concat specifically needs to be changed. But it is the only Array method that does that check (the only other internal checks for brand BuiltinArray are in apply and isArray I think). On Mon, Dec 31, 2012 at 1:33 PM, Erik Arvidsson wrote: > On Sun, Dec 30, 2012 at 6:05 PM, Brandon Benvie >

Re: Why does legacy content break when making array-likes real arrays?

On Sun, Dec 30, 2012 at 6:05 PM, Brandon Benvie wrote: > The primary issue is that most array-likes aren't array-like when it comes > to mutability. Most exposed indexed objects don't allow changes to their > indices, which is decidedly un-array-like for ~quarter of array operations. The issue is

Re: 10 biggest JS pitfalls

Le 31 déc. 2012 à 18:58, Axel Rauschmayer a écrit : >> Personally, I have issues with from- and to-String conversions when working >> with HTML form field values and data-* attributes. More precisely, I am >> careful to make these conversions manually, and I regret that JS doesn't >> warn me

Better property behavior

Currently making a typo in property names can be fatal in two ways: When reading a property, things fail silently and you get back `undefined`. When setting a property, you accidentally create a new property. A safer behavior would be as follows: 1. Creating properties 1a. Only property def

Re: excluding features from sloppy mode

> (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 iden

Re: 10 biggest JS pitfalls

> Personally, I have issues with from- and to-String conversions when working > with HTML form field values and data-* attributes. More precisely, I am > careful to make these conversions manually, and I regret that JS doesn't warn > me if I forget to do them. Indeed the following cases are prob

Re: 10 biggest JS pitfalls

On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote: > I'm surprised not to see Automatic Semicolon Insertion in the list. Yes I would ditch ASI altogether if only to force the javascrhipsters to put back each and every semicolon where it belongs: they are *delimiters*. No ASI would force them t

Re: 10 biggest JS pitfalls

Le 31 déc. 2012 à 10:17, Axel Rauschmayer a écrit : >>> I’d be interested in other examples of implicit conversions stumping people. >> >> What stumped who, when? Any bugs/github issues/blog posts to cite? > > No, I think I agree with your assessment that implicit conversion to boolean > (the

Re: [[SetInheritance]] (was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

On Monday, December 31, 2012, Tom Van Cutsem wrote: > > That said, I think this issue is orthogonal to our choice of whether or > not to expose "setPrototypeOf" as part of the MOP. Even if we do expose > it, any sandbox that wants to take away the ability the set the prototype > can simply poison R

Re: 10 biggest JS pitfalls

I'm surprised not to see Automatic Semicolon Insertion in the list. Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: On defining non-standard exotic objects

Hi David, I generally support this view, although it may be too restrictive to completely disallow non-standard exotics. Instead, I would be happy if we could just state that non-standard exotics are expected to uphold "the invariants of the ES6 object model", which will presumably be codified in

Symbol toString behavior (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

2012/12/31 Allen Wirfs-Brock > responses for chapter 8, except for 8.5 which will get its own message. > > On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote: > > 8.4.4 Exotic Symbol Objects > > Typo: "A{n} Symbol object is an exotic object…" > > "Exotic String objects have {the} a..." > fixed >

Return values of mutating MOP operations (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

2012/12/31 Allen Wirfs-Brock > responses for chapter 8, except for 8.5 which will get its own message. > > > On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote: > > Table 8: > > * [[PreventExtensions]] internal method: should return a Boolean > success value > > Why? no caller of [[PreventExten

Property descriptor normalization (Was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

2012/12/30 Allen Wirfs-Brock > > On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote: > > * I'm a bit uncomfortable with the removal of property descriptor > normalization in the getOwnPropertyDescriptor/defineProperty traps. > Especially for getOwnPropertyDescriptor I think it's a breaking change

[[SetInheritance]] (was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

2012/12/30 Allen Wirfs-Brock > > On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote: > > * [[SetInheritance]]/Reflect.setPrototypeOf: I'm not sure this was > agreed upon. Especially since __proto__ is currently specified as a data > property. This means there is no setter that separately reifies

Re: WebIDL attribute reflection

Le 31/12/2012 07:19, Boris Zbarsky a écrit : On 12/30/12 1:20 PM, Claude Pache wrote: FWIW, I used the fact that, in IE 8 & 9, innerHTML is conveniently a configurable accessor found at Element.prototype (in IE8) or HTMLElement.prototype (in IE9), for correcting a quirk of its setter, by extra

Re: 10 biggest JS pitfalls

>> I’d be interested in other examples of implicit conversions stumping people. > > What stumped who, when? Any bugs/github issues/blog posts to cite? No, I think I agree with your assessment that implicit conversion to boolean (the most prevalent implicit conversion) is manageable, possibly eve