Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron waldron.r...@gmail.com wrote:
Can you clarify write? Does this mean assignment?
Yes.
Why would assignment throw?
Assigning to an uninitialized variable is an error in ES6. A
let-binding is initialized when its declaration is evaluated. So this
is OK:
let x; // no Initializer, so it's initialized to undefined
console.log(x); // logs undefined
but this is not:
init();
let answer;
function init() {
answer = 42; // throws ReferenceError
}
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems bad. I guess we can fix this by making the REPL bend the rules of the language. But this is rather hard to do for REPLs implemented in JS. Maybe the rules should just be a little more forgiving. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Event loops in navigated-away-from windows
Le 29/09/2014 23:08, Anne van Kesteren a écrit : On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote: I certainly wouldn't object to the ES spec's event loop algorithms being turned inside out (search for RunCode on the esdiscuss thread above for an e-mail where I propose this) but that would be purely an editorial change, it wouldn't change the implementations. The proposed setup from Allen will start failing the moment ECMAScript wants something more complicated with its loop. How likely is this? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from what I know (corrections welcome0. Hm, people most often refer to mandatory tail call optimisation/elimination when talking about a spec level requirement. I have never seen PTC used in a formal context, let alone the acronym. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Boris' point seems to be -- and I agree -- that such a test would only
be a semi-decision procedure. I.e., it can only falsify, but not
validate the property for the test program.
/Andreas
On 30 September 2014 04:48, Brendan Eich bren...@mozilla.org wrote:
Put it in a worker or node.js. The point Sam was making was based on
Ecma-262, no browser watchdog required.
/be
On Sep 29, 2014, at 6:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
How would you know whether it does? You can't tell whether your program is
terminated because it runs out of space or because the browser has decided
it's hung and killed it
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote: I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems bad. No surprise. One of the reasons why I always favoured a nested scopes model for multiple scripts... /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
John Lenz, using source URLs for naming eval'ed code in the traceback provided to `window.onerror` isn't a de-facto standard; only V8 does it?? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
I remember web compat concerns, but if Chrome is exposing the `//# sourceURL` to the web in error stacks, maybe we can get away with it as well. I'd defer to jorendorff's opinion on this. We've also discussed exposing the source mapped location of stack frames to JS, but that's even trickier: * We don't do any source mapping unless devtools are open, so exposing this would leak whether the user is using devtools or not. Not sure how serious that is, but it makes me hesitant. On the other hand, always source mapping seems impractical, but maybe that's a false assumption. * It is a nonstarter to block JS on fetching a source map, so early stack traces would not be source mapped, while later ones would be. This sort of non-determinism makes me feel :( We could introduce a new async method for getting stacks and only source map for these async stacks (or make the new method that other branches of this thread are discussing async). Interested in hearing everyone's thoughts on this. Cheers, _Nick_ On Tue, Sep 30, 2014 at 3:44 AM, John Lenz concavel...@gmail.com wrote: It is a defacto standard. On Sep 29, 2014 6:36 PM, Brendan Eich bren...@mozilla.org wrote: Carl Smith wrote: If the source URL hack, or some cleaner wrapper for it, was standardised, it'd make all the difference. Why don't we just make the source URL hack a de-facto standard? That's how evolution happens, in the best case. Cc'ing @fitzgen. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg rossb...@google.com wrote: On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from what I know (corrections welcome0. Hm, people most often refer to mandatory tail call optimisation/elimination when talking about a spec level requirement. I have never seen PTC used in a formal context, let alone the acronym. Clinger's paper, which formalizes the concept, calls it proper tail recursion in the title, as does the R5RS Scheme standard. Since recursion isn't fundamental, though, proper tail calls seems more accurate. This terminology is used lots of places these days, such as the Lua docs and this (archive of a) post by Guy Steele: http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 30 September 2014 16:31, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg rossb...@google.com wrote: On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from what I know (corrections welcome0. Hm, people most often refer to mandatory tail call optimisation/elimination when talking about a spec level requirement. I have never seen PTC used in a formal context, let alone the acronym. Clinger's paper, which formalizes the concept, calls it proper tail recursion in the title, as does the R5RS Scheme standard. Since recursion isn't fundamental, though, proper tail calls seems more accurate. This terminology is used lots of places these days, such as the Lua docs and this (archive of a) post by Guy Steele: http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html Interesting, good to know. Thanks for the clarification. (Still wondering what improper tail calls would be.) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
Likewise. E is also a scripting repl language with dynamic types and static scopes. We tried a variety of different ways to handle the top level repl and nested scopes were best. On Sep 30, 2014 4:04 AM, Andreas Rossberg rossb...@google.com wrote: On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote: I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems bad. No surprise. One of the reasons why I always favoured a nested scopes model for multiple scripts... /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
I don't believe we want source map involved as, as you say, that information needs to be retrieved separately. On Sep 30, 2014 5:17 AM, Fitzgerald, Nick nfitzger...@mozilla.com wrote: On 9/30/14, 3:44 AM, John Lenz wrote: It is a defacto standard. On Sep 29, 2014 6:36 PM, Brendan Eich bren...@mozilla.org wrote: Carl Smith wrote: If the source URL hack, or some cleaner wrapper for it, was standardised, it'd make all the difference. Why don't we just make the source URL hack a de-facto standard? That's how evolution happens, in the best case. Cc'ing @fitzgen. /be I remember web compat concerns, but if Chrome is exposing the `//# sourceURL` to the web in error stacks, maybe we can get away with it as well. I'd defer to jorendorff's opinion on this. We've also discussed exposing the source mapped location of stack frames to JS, but that's even trickier: * We don't do any source mapping unless devtools are open, so exposing this would leak whether the user is using devtools or not. Not sure how serious that is, but it makes me hesitant. On the other hand, always source mapping seems impractical, but maybe that's a false assumption. * It is a nonstarter to block JS on fetching a source map, so early stack traces would not be source mapped, while later ones would be. This sort of non-determinism makes me feel :( We could introduce a new async method for getting stacks and only source map for these async stacks (or make the new method that other branches of this thread are discussing async). Interested in hearing everyone's thoughts on this. Cheers, Nick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Tue, Sep 30, 2014 at 6:38 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron waldron.r...@gmail.com
wrote:
Can you clarify write? Does this mean assignment?
Yes.
Why would assignment throw?
Assigning to an uninitialized variable is an error in ES6. A
let-binding is initialized when its declaration is evaluated. So this
is OK:
let x; // no Initializer, so it's initialized to undefined
console.log(x); // logs undefined
but this is not:
init();
let answer;
function init() {
answer = 42; // throws ReferenceError
}
My original response questions were poorly asked. I understand the TDZ
semantics, but I couldn't reproduce anything meaningful from your original
example, because I don't have the SpiderMonkey build that includes the let
updates (presumably Nightly doesn't either, because none of these can be
reproduced there). I'm trying to understand when/where/why/how the original
example could happen and what the potential consequences are in terms of
practical application.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example, because I don't have the SpiderMonkey build that includes the let updates (presumably Nightly doesn't either, because none of these can be reproduced there). I'm trying to understand when/where/why/how the original example could happen and what the potential consequences are in terms of practical application. Also, note that IE11 apparently implements the ES6 let semantics so it may be useful to look at its experience in this regard. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example, because I don't have the SpiderMonkey build that includes the let updates (presumably Nightly doesn't either, because none of these can be reproduced there). I'm trying to understand when/where/why/how the original example could happen and what the potential consequences are in terms of practical application. Also, note that IE11 apparently implements the ES6 let semantics so it may be useful to look at its experience in this regard. As a Mac user, I completely forgot about this. Using Browserstack.com, I was able to reproduce the original example's behavior by running a script and then attempting to access or assign to x from the console. The behavior I observe is exactly what I expect. I'm still unable to provide any further insight regarding Jason's original comments and practical implications of reported behavior. That by itself isn't necessarily a problem. I've never written a web page where I wanted to recover after a toplevel script threw an exception (or timed out). I agree with the first assertion for the same reason stated. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
FYI, you can also see this behavior in Node.js (v0.11.14) node --harmony --strict-mode On Tue, Sep 30, 2014 at 1:24 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example, because I don't have the SpiderMonkey build that includes the let updates (presumably Nightly doesn't either, because none of these can be reproduced there). I'm trying to understand when/where/why/how the original example could happen and what the potential consequences are in terms of practical application. Also, note that IE11 apparently implements the ES6 let semantics so it may be useful to look at its experience in this regard. As a Mac user, I completely forgot about this. Using Browserstack.com, I was able to reproduce the original example's behavior by running a script and then attempting to access or assign to x from the console. The behavior I observe is exactly what I expect. I'm still unable to provide any further insight regarding Jason's original comments and practical implications of reported behavior. That by itself isn't necessarily a problem. I've never written a web page where I wanted to recover after a toplevel script threw an exception (or timed out). I agree with the first assertion for the same reason stated. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Tue, Sep 30, 2014 at 2:08 PM, Brian Genisio briangeni...@gmail.com wrote: FYI, you can also see this behavior in Node.js (v0.11.14) node --harmony --strict-mode V8's support of let is far from spec compliant. Stuff under --harmony is incomplete, buggy and may have security holes. Do not use! -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
Bug in MooTools is not a reason to make any method of Array.prototype enumerable. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
On 30 September 2014 17:28, John Lenz concavel...@gmail.com wrote: I don't believe we want source map involved as, as you say, that information needs to be retrieved separately. I seems there's three parts to this. One is allowing evals to be named the way Chrome does, and providing line and column numbers for both caught and uncaught errors. Another is improving the stack traces, providing an array of hashes instead of a string. The last is source map support. I don't personally see any reason to bundle this stuff into one issue. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Just to be clear, you can convert a stack trace into a struct pretty easily, and then do source mapping on it with Mozilla Source Maps. This already works. I can see why a console would provide integrated source map support, but no reason for that to be exposed to client code. It's only a rarely used, pure convenience outside of dev tools. From a humble Web dev's point of view, the important distinction is between what I depend on the browser for, and what I can fix myself. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On 9/30/14, 2:45 PM, Michał Wadas wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. I didn't say we need to make it enumerable. I said that given the current state of the web, a web browser cannot ship a non-enumerable method named contains on Array.prototype. The options, therefore, are: 1) Make the method enumerable. 2) Name the method something else. 3) Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago). I'm perfectly fine with option 3, personally. Note that in practice that likely means never ship it unless people make some sort of concerted effort to get sites to update their MooTools version. -Boris P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. It's also common on the old web to loop over Arrays via `for/in` to avoid checks for sparse indexes through the entire length ... so making anything enumerable in that native prototype would break something else too form days where `getOwnPropertyNames` was unknown. long story short: I definitively +1 what Michał Wadas already said, it's already patched and people must update software anyway due security problems, **patches**, etc etc. just my .02 On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 2:45 PM, Michał Wadas wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. I didn't say we need to make it enumerable. I said that given the current state of the web, a web browser cannot ship a non-enumerable method named contains on Array.prototype. The options, therefore, are: 1) Make the method enumerable. 2) Name the method something else. 3) Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago). I'm perfectly fine with option 3, personally. Note that in practice that likely means never ship it unless people make some sort of concerted effort to get sites to update their MooTools version. -Boris P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
MooTools breaking because of additions/changes is not a new thing. It has been broken in the past by things like Function#bind, String#contains, Moz removing document.getBoxObjectFor. Its activity has slowed overall though there is an effort to re-energize core contributions. Their core has put effort towards another project, Prime, which does not augment native prototypes. -JDD On Tue, Sep 30, 2014 at 12:45 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. It's also common on the old web to loop over Arrays via `for/in` to avoid checks for sparse indexes through the entire length ... so making anything enumerable in that native prototype would break something else too form days where `getOwnPropertyNames` was unknown. long story short: I definitively +1 what Michał Wadas already said, it's already patched and people must update software anyway due security problems, **patches**, etc etc. just my .02 On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 2:45 PM, Michał Wadas wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. I didn't say we need to make it enumerable. I said that given the current state of the web, a web browser cannot ship a non-enumerable method named contains on Array.prototype. The options, therefore, are: 1) Make the method enumerable. 2) Name the method something else. 3) Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago). I'm perfectly fine with option 3, personally. Note that in practice that likely means never ship it unless people make some sort of concerted effort to get sites to update their MooTools version. -Boris P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
The problem is not people actively developing it, or creating new content with it. The problem is _existing_ content that might break. All libraries have periods where they are in vogue, and then fade out leaving detritus that hangs around for years/decades on major sites. --Oliver On Sep 30, 2014, at 12:45 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. It's also common on the old web to loop over Arrays via `for/in` to avoid checks for sparse indexes through the entire length ... so making anything enumerable in that native prototype would break something else too form days where `getOwnPropertyNames` was unknown. long story short: I definitively +1 what Michał Wadas already said, it's already patched and people must update software anyway due security problems, **patches**, etc etc. just my .02 On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 9/30/14, 2:45 PM, Michał Wadas wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. I didn't say we need to make it enumerable. I said that given the current state of the web, a web browser cannot ship a non-enumerable method named contains on Array.prototype. The options, therefore, are: 1) Make the method enumerable. 2) Name the method something else. 3) Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago). I'm perfectly fine with option 3, personally. Note that in practice that likely means never ship it unless people make some sort of concerted effort to get sites to update their MooTools version. -Boris P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course. ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 3:45 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. Seconded—arguably MooTools' decline in usership is because of conflicts such as this. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 4:02 PM, Oliver Hunt oli...@apple.com wrote: The problem is not people actively developing it, or creating new content with it. The problem is _existing_ content that might break. All libraries have periods where they are in vogue, and then fade out leaving detritus that hangs around for years/decades on major sites. In these cases, evangelism over the next two years will help. Most major sites are also maintained sites, which means there is time to work on getting the necessary fixes implemented. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Having a non-enumerable Array.prototype.contains may not be web-compatible
Welp, nothing to do but add @@unMooToolsables. From: Boris Zbarskymailto:bzbar...@mit.edu Sent: 2014-09-30 19:21 To: es-discussmailto:es-discuss@mozilla.org Subject: Having a non-enumerable Array.prototype.contains may not be web-compatible See https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 for a case it breaks, for example. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On 9/30/14, 3:45 PM, Andrea Giammarchi wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. They have ears, but cannot hear... This is a reasonably commonly used library, as libraries go. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 3:45 PM, Andrea Giammarchi wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. They have ears, but cannot hear... This is a reasonably commonly used library, as libraries go. This may be helpful: http://trends.builtwith.com/javascript/javascript-library Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Sep 30, 2014, at 4:03 AM, Andreas Rossberg rossb...@google.com wrote: On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote: I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems bad. No surprise. One of the reasons why I always favoured a nested scopes model for multiple scripts... We've had this debate a million times, but for anyone who's unfamiliar with the arguments: nested scopes makes recursive bindings across scripts impossible and is also hard to understand with things like asynchronous script execution order (such as script async). And it's totally different from the existing mental model of global code. But since we're rehashing, this is an example of why *I've* always thought new binding forms should just go in the global object just like vars and functions do. JS's global scope is extremely complex and subtle, and you can't undo that complexity by adding additional layers. And the metal model, while unfortunate, already occupies programmers' brainspace -- adding an extra layer of scope for some binding forms makes the mental model more complex. We basically have the following set of constraints that various people have tossed into the mixing bowl. It seems no matter which way you mix it, at least one of the constraints falls back out of the bowl: 1. Make `let` mean the same thing at top-level that it means locally. 2. Enable recursive bindings across multiple scripts. 3. Avoid the spec/design work of reifying new binding forms' reification in the global object. 4. Preserve the mental model of the global object. Note that, as so often happens, we have one dimension of consistency (scoping semantics of `let` in local vs. global contexts) in tension with another dimension of consistency (globals going in the global object vs. globals going in a new scope layer). I'm still convinced we made the wrong call, i.e., we chose the wrong dimension of consistency. The global scope was always a mess and we aren't going to make it less of a mess no matter what we do. We favored a philosophical consistency over a historical consistency, with predictable results. But it is what it is. We've talked before about exposing a reflection of the extra global layer, maybe via the Reflect API but certainly through the Realm API. We may need to add controls to that to allow undoing these kinds of annoyances Jason brings up. I'm usually less concerned about REPLs, since they can decide for themselves what kind of context they want to execute in -- or even invent new non-standard non-terminals, frankly -- although in this case it's not quite clear what a let declaration *should* do in the REPL. Maybe developer consoles should actually treat `let` the way IMO we should've done for scripts. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains. - JDD On Tue, Sep 30, 2014 at 1:29 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 3:45 PM, Andrea Giammarchi wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. They have ears, but cannot hear... This is a reasonably commonly used library, as libraries go. This may be helpful: http://trends.builtwith.com/javascript/javascript-library Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On 9/30/14, 4:29 PM, Rick Waldron wrote: This may be helpful: http://trends.builtwith.com/javascript/javascript-library Rick, thank you! This says 1.32% on top 10k sites, 3.05% on top 100k sites, 4.78% on top million sites, and 6.39% overall. There's definitely been a recent dip in those numbers, of course. Used to be even higher. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
On Tue, Sep 30, 2014 at 12:00 PM, Rick Waldron waldron.r...@gmail.com wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example, because I don't have the SpiderMonkey build that includes the let updates (presumably Nightly doesn't either, because none of these can be reproduced there). SpiderMonkey doesn't conform to the draft spec yet. We implemented TDZ in functions, but not at toplevel. 'const' isn't lexical yet. There's a lot more work to do. I'm trying to understand when/where/why/how the original example could happen and what the potential consequences are in terms of practical application. Purely hypothetical for us, for now. It came up on IRC. Some engineers were discussing the breaking changes we're going to have to make. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas michalwa...@gmail.com wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. Well -- true, that would break even more sites. We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contribution. In the long run, perhaps renaming it is the best course? :-\ -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
There is no need to change the name. MooTools has had these issues in the past (they've broke with ES5, ES6, ES7 methods). Array#contains is ES7 so there's time for their patch to release/propagate. - JDD On Tue, Sep 30, 2014 at 3:04 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas michalwa...@gmail.com wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. Well -- true, that would break even more sites. We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contribution. In the long run, perhaps renaming it is the best course? :-\ -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems. Should ES7 be planned around all methods already taken in there? I don't think so + it is also already patched and it's also a small fix. If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway. Best Regards On Tue, Sep 30, 2014 at 9:02 PM, Oliver Hunt oli...@apple.com wrote: The problem is not people actively developing it, or creating new content with it. The problem is _existing_ content that might break. All libraries have periods where they are in vogue, and then fade out leaving detritus that hangs around for years/decades on major sites. --Oliver On Sep 30, 2014, at 12:45 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the current state of the web ... with all due respect for that library, it's been years since I've heard anything about it. It's also common on the old web to loop over Arrays via `for/in` to avoid checks for sparse indexes through the entire length ... so making anything enumerable in that native prototype would break something else too form days where `getOwnPropertyNames` was unknown. long story short: I definitively +1 what Michał Wadas already said, it's already patched and people must update software anyway due security problems, **patches**, etc etc. just my .02 On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 2:45 PM, Michał Wadas wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. I didn't say we need to make it enumerable. I said that given the current state of the web, a web browser cannot ship a non-enumerable method named contains on Array.prototype. The options, therefore, are: 1) Make the method enumerable. 2) Name the method something else. 3) Don't ship the method until every site that currently uses the buggy versions of MooTools (which is every site that uses MooTools, since they only fixed it 4 days ago). I'm perfectly fine with option 3, personally. Note that in practice that likely means never ship it unless people make some sort of concerted effort to get sites to update their MooTools version. -Boris P.S. It may be worth avoiding the method names mootools sets up but doesn't force-copy in the future. Even better would be getting them to fix their code so there are no such method names, of course. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
John-David Dalton wrote: Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains. Did you ask them to fix their code so it doesn't fail for any name, not just for 'contains'? Thanks, /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Toplevel 'let' binding can be left permanently uninitialized after an error
David Herman wrote: I'm usually less concerned about REPLs, since they can decide for themselves what kind of context they want to execute in -- or even invent new non-standard non-terminals, frankly -- although in this case it's not quite clear what a let declaration*should* do in the REPL. Maybe developer consoles should actually treat `let` the way IMO we should've done for scripts.:) Agree that nesting is a bad idea for script top level scopes. But a REPL might be the one place nesting works to avoid the issue Jason raised. Any gotchas there? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
Did you ask them to fix their code so it doesn't fail for any name, not just for 'contains'? Thanks, I didn't, but will follow up with that. JDD On Tue, Sep 30, 2014 at 3:50 PM, Brendan Eich bren...@mozilla.org wrote: John-David Dalton wrote: Just a heads up, I've pinged MooTools core to inquire about fast-pathing a patch release for Array#contains. Did you ask them to fix their code so it doesn't fail for any name, not just for 'contains'? Thanks, /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems. Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that. it is also already patched and it's also a small fix. The 6.5% of existing web sites using JS libraries that use MooTools have not been already patched. Patching 3.5 million web sites is not a small fix in any relevant sense. It simply will not be done thoroughly or soon. If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway. Yes. You have correctly identified incentives as a problem. That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. Reductio ad the-world-is-not-as-I-wish-it-to-be is not a thing. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 6:04 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas michalwa...@gmail.com wrote: Bug in MooTools is not a reason to make any method of Array.prototype enumerable. Well -- true, that would break even more sites. We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contribution. In the long run, perhaps renaming it is the best course? :-\ Unfortunately, it's named to match String.prototype.contains and Domenic made strong cases in his proposal and presentation for `contains` over alternatives Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
On Tue, Sep 30, 2014 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems. Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that. I support your decision to back it out for now and the foreseeable future. This will give devs a chance to evangelize the necessary updates. Rick it is also already patched and it's also a small fix. The 6.5% of existing web sites using JS libraries that use MooTools have not been already patched. Patching 3.5 million web sites is not a small fix in any relevant sense. It simply will not be done thoroughly or soon. If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway. Yes. You have correctly identified incentives as a problem. That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. Reductio ad the-world-is-not-as-I-wish-it-to-be is not a thing. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Having a non-enumerable Array.prototype.contains may not be web-compatible
So put ES7 features behind a flag until the water clears a bit. We'll get there. It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again. JDD On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems. Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that. it is also already patched and it's also a small fix. The 6.5% of existing web sites using JS libraries that use MooTools have not been already patched. Patching 3.5 million web sites is not a small fix in any relevant sense. It simply will not be done thoroughly or soon. If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway. Yes. You have correctly identified incentives as a problem. That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. Reductio ad the-world-is-not-as-I-wish-it-to-be is not a thing. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Having a non-enumerable Array.prototype.contains may not be web-compatible
You guys are much more optimistic than I am about this ever being shippable. I am starting a new thread to investigate solutions that don’t involve waiting for indeterminate amounts of time, but of course if we can somehow fix the MooTools-using web and not change anything about Array.prototype.contains, that would be ideal. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton Sent: Wednesday, October 1, 2014 00:55 To: Jason Orendorff Cc: es-discuss Subject: Re: Having a non-enumerable Array.prototype.contains may not be web-compatible So put ES7 features behind a flag until the water clears a bit. We'll get there. It kind of surprises me (a good surprise) that now, because of JSFiddle, there's super interest in MooTools. When in the past, when MooTools was arguably more popular, it didn't stop the language and browsers from breaking them over and over again. JDD On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff jason.orendo...@gmail.commailto:jason.orendo...@gmail.com wrote: On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote: I'm personally against unmaintained code and/or websites but here it's not ES7 breaking the web, it's a library already broken (somehow) due native prototype pollution without a mechanism to prevent these, apparently historically known, problems. Either way, you're telling me I should ship a browser that chokes on thousands of web sites that work fine today. That would be bad for our users, so I'm not planning on doing that. it is also already patched and it's also a small fix. The 6.5% of existing web sites using JS libraries that use MooTools have not been already patched. Patching 3.5 million web sites is not a small fix in any relevant sense. It simply will not be done thoroughly or soon. If sites and developers have no reason to update code 'cause ES7 cannot release until they'll change a file ... why would they anyway. Yes. You have correctly identified incentives as a problem. That does not constitute a reductio proof that browser vendors must ignore their users' interests and break the web. Reductio ad the-world-is-not-as-I-wish-it-to-be is not a thing. -j ___ es-discuss mailing list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.contains solutions
This is a follow-up thread to discuss how to solve the problem identified in http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible without breaking the web. (Any arguments that it is OK to break sites using MooTools, please stay in that thread and respectfully do *not* reply to this one.) --- So, guess that proves I should never say this will be easy! before working on a feature. Yay, the web. I see a few options: 1. Rename. The leading candidate would be `Array.prototype.has`. I outlined in [1] why `contains` is better; note especially the DOM classes. But you could stretch things, especially by removing the `fromIndex` parameter, into an argument that `has` is OK. (Basically, you'd be saying that an array is more like a set than a map, and that its analogy with String is mostly accidental.) 2. Specific hacks. I am thinking of e.g. making `Array.prototype.contains` a getter, with a setter that does [[DefineOwnProperty]]. 3. General hacks. I joked about @@unMooToolsables, but seriously, we could do something similar to @@unscopables of using MOP hooks to fix this problem. One idea that seems reasonable is @@enumerableWhenAssigned, so that `Array.prototype.contains` starts non-enumerable, but when you do `Array.prototype.contains = x`, it becomes enumerable. You could even generalize this into something that also fixes the override mistake [2], e.g. @@defineOwnPropertyOnAssign or @@assignIgnoresProto or similar. Or you could attack the problem at the for-in level --- 1 is tempting in its simplicity. 2 is pretty gross and we'd probably be better of throwing out the feature. 3 is intriguing, although it obviously adds complexity cost to a feature that was supposed to be trivial. I am curious if there is any support for 3, or proposals for a better hack in that vein. Because we will also have this problem for any other prototype extensions that work in the same way, e.g. MooTools's `flatten` (which seems like something we'd likely want) or their `associate`, `link`, `getRandom`, `combine`, or `pick` (which seem less likely). And I assume the problem could extend beyond MooTools, and possibly beyond Array. (Although, Array is a special case in that we can't make any of its methods enumerable.) Especially if we choose something more general, e.g. @@assignIgnoresProto, I could see this being a powerful tool for fighting such problems in the future, and maybe for helping fix the override mistake (although I don't understand all of the use cases involved there). [1]: https://github.com/domenic/Array.prototype.contains/#why-contains-instead-of-has [2]: http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Array.prototype.contains solutions
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola Or you could attack the problem at the for-in level This half-sentence was a leftover from an earlier pass; please ignore it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Throwing errors on mutating immutable bindings
Hi all,
In the current draft, I see 2 different places where assigning to an immutable
binding ('const') throws an error:
1) Dynamically throwing a TypeError in SetMutableBinding,
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s
2) Statically throwing a Syntax Error in assignment expressions,
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors
1) throws only in strict mode code, while 2) throws regardless. 2) is also best
effort; seems to be implementation-dependent what can statically determine
entails.
Is the intention that assigning to consts silently nops if the implementation
cannot determine the assignment to be to a const statically, in non-strict
code, but implementations *should* make a best effort to report such cases
eagerly, regardless of strictness? Seems kind of odd to me; perhaps I am
misreading?
--
shu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains solutions
A more general solution seems like a good idea. Renaming doesn't really solve the deeper issue. Extending native prototypes is a JavaScript thing and something that will most likely continue continue. Ember adds methods to Array.prototype and Function.prototype by default: http://emberjs.com/api/classes/Ember.Array.html#method_contains (btw their Array#contains is not ES7 spec compliant either) then there's the oldie Prototype.js: http://api.prototypejs.org/ and alternatives like Sugar.js: http://sugarjs.com/api that's a lot to watch out for. JDD On Tue, Sep 30, 2014 at 5:03 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola Or you could attack the problem at the for-in level This half-sentence was a leftover from an earlier pass; please ignore it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains solutions
On 9/30/14, 8:12 PM, John-David Dalton wrote: Extending native prototypes is a JavaScript thing and something that will most likely continue continue. Note that if people were extending in nice ways, using defineProperty and making their props non-enumerable instead of just doing a [[Set]], that would significantly reduce issues like this... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains solutions
Maybe. Though there would still be issues with implementations not aligning, like Ember which does use defineProperty to make them non-enumerable and doesn't pave existing methods, as well as issues with scripts that support pre-ES5 environments that don't want enumerable inconsistency. JDD On Tue, Sep 30, 2014 at 5:15 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/30/14, 8:12 PM, John-David Dalton wrote: Extending native prototypes is a JavaScript thing and something that will most likely continue continue. Note that if people were extending in nice ways, using defineProperty and making their props non-enumerable instead of just doing a [[Set]], that would significantly reduce issues like this... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maximally minimal stack trace standardization
Sorry, I didn't mean to kind of hijack the thread. Just read it back. Really just wanted to share the point of view of someone who actually has to provide tracebacks to the user as a central feature in an app. It's difficult, but doable, but only in Chrome/Opera. Pragmatically, it'd just be nice if FireFox did the named eval thing so it wasn't an engine specific hack. That'd be close enough to a standard for a lot of cases. Other vendors are what they are. Cheers all ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains solutions
On Tue, Sep 30, 2014 at 4:58 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
This is a follow-up thread to discuss how to solve the problem identified
in
http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible
without breaking the web. (Any arguments that it is OK to break sites using
MooTools, please stay in that thread and respectfully do *not* reply to
this one.)
---
So, guess that proves I should never say this will be easy! before
working on a feature. Yay, the web.
I see a few options:
1. Rename. The leading candidate would be `Array.prototype.has`. I
outlined in [1] why `contains` is better; note especially the DOM classes.
But you could stretch things, especially by removing the `fromIndex`
parameter, into an argument that `has` is OK. (Basically, you'd be saying
that an array is more like a set than a map, and that its analogy with
String is mostly accidental.)
If we do rename, it should be almost anything other than .has. Arrays are
clearly single-valued-mapping-like, not set-like, in that they map from
indexes to values. If Array.prototype.has were to exist, it would need to
test possible indexes.
2. Specific hacks. I am thinking of e.g. making `Array.prototype.contains`
a getter, with a setter that does [[DefineOwnProperty]].
This could work, and it requires no new kernel mechanisms. If we do adopt
this solution, the setter should be careful to play the same games that SES
plays to work around the override mistake: If the this being set is not
Array.prototype itself, the setter should use [[DefineOwnProperty]] to
emulate an assignment to that this's own .contains.
3. General hacks. I joked about @@unMooToolsables, but seriously, we could
do something similar to @@unscopables of using MOP hooks to fix this
problem. One idea that seems reasonable is @@enumerableWhenAssigned, so
that `Array.prototype.contains` starts non-enumerable, but when you do
`Array.prototype.contains = x`, it becomes enumerable. You could even
generalize this into something that also fixes the override mistake [2],
e.g. @@defineOwnPropertyOnAssign or @@assignIgnoresProto or similar. Or you
could attack the problem at the for-in level
I suggest we focus on the override mistake. If we come up with a way of
fixing it and .contains with one new kernel mechanism, that would be great.
If we only fix the override mistake, still likely worth it. But if a new
kernel mechanism only fixes .contains, it likely isn't worth it and we
should return to #1 or #2.
---
1 is tempting in its simplicity. 2 is pretty gross and we'd probably be
better of throwing out the feature. 3 is intriguing, although it obviously
adds complexity cost to a feature that was supposed to be trivial.
I am curious if there is any support for 3, or proposals for a better hack
in that vein. Because we will also have this problem for any other
prototype extensions that work in the same way, e.g. MooTools's `flatten`
(which seems like something we'd likely want) or their `associate`, `link`,
`getRandom`, `combine`, or `pick` (which seem less likely). And I assume
the problem could extend beyond MooTools, and possibly beyond Array.
(Although, Array is a special case in that we can't make any of its methods
enumerable.)
Especially if we choose something more general, e.g. @@assignIgnoresProto,
I could see this being a powerful tool for fighting such problems in the
future, and maybe for helping fix the override mistake (although I don't
understand all of the use cases involved there).
[1]:
https://github.com/domenic/Array.prototype.contains/#why-contains-instead-of-has
[2]:
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake
The most painful use case is the existence of perfectly reasonable ES5 code
like:
function Point(x, y) { this.x = x; this.y = y; }
Point.prototype.toString() { return `${x},${y}`; };
Because of the override mistake, this reasonable code no longer works after
Object.freeze(Object.prototype);
This sucks.
SES goes out of its way to not break code that follows ES5 best practices.
The above Point code does. That's why SES's tamperProof(Object.prototype)
replaces the data properties on Object.prototype with accessor properties
whose setter uses [[DefineOwnProperty]] to emulate assignment on a this
that is not Object.prototype itself.
With your #3, perhaps we'd have a less painful way to working around the
override mistake.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
