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
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
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
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
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
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
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
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:
*
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
___
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.
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
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,
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.
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
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
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
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
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
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
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:
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]],
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
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
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.
52 matches
Mail list logo
