many MDN examples are on jsfiddle ...maybe one of the reasons? Although I
wasn't suggesting to break everything, rather saying that changing name should
not be an option.
-Original Message-
From: John-David Dalton john.david.dal...@gmail.com
Sent: 01/10/2014 00:54
To: Jason
Mark S. Miller wrote:
On Tue, Sep 30, 2014 at 4:58 PM, Domenic Denicola
dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote:
I see a few options:
1. Rename. The leading candidate would be `Array.prototype.has`. I
outlined in [1] why `contains` is better; note
1. I wasn't advocating to break the web but to **not** change the name
because of a library bug, the initial thread spoiler was not needed
2. the `@@enumerableWhenAssigned` might lead to shenanigans but it's
*polyfillable* which is IMO preferable if it can solve somehow the problem
```js
On 30 September 2014 22:38, David Herman dher...@mozilla.com wrote:
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
Andrea Giammarchi wrote:
1. I wasn't advocating to break the web but to **not** change the
name because of a library bug, the initial thread spoiler was not needed
I wasn't responding to you, here on this thread (where you hadn't posted
till now) or on the other one, so why are you jumping
Le 1 oct. 2014 à 04:43, Mark S. Miller erig...@google.com a écrit :
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
Thanks Claude for filling in some of the details in my vague thinking. I guess
I/we should try to come up with something more detailed, and see how/if it is
able to address Mark's use cases, and how implementable it would be, and how
extensively it would help (or not).
I tend to agree with
The more I consider the issue, the more I think that the most elegant solution
is to complete data properties with an additional overridable attribute,
whose purpose is to refine the meaning of the writable attribute in the
manner sketched below (in opposition of having an @@unscopables-like
On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich bren...@mozilla.org wrote:
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}`; };
You mean
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a
full parse of the function.
I think we need to either enforce this or remove this restriction. Anything
in between will lead to inconsistent behavior
JSC does lazy parsing of nested functions and we have no problem reporting
static errors, so i’m not sure what you believe is the problem here.
—Oliver
On Oct 1, 2014, at 7:09 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines
On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt oli...@apple.com wrote:
JSC does lazy parsing of nested functions and we have no problem reporting
static errors, so i’m not sure what you believe is the problem here.
Hi Oliver,
First, I agree with you. This shouldn't be a problem.
However, both
On Oct 1, 2014, at 7:09 AM, Erik Arvidsson wrote:
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a full
parse of the function.
I think we need to either enforce this or remove this
On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote:
...
I was with you until you got to the following point
If there is an intervening with or sloppy direct eval, then there is not a
statically apparent assignment to a const variable. Since this can only occur
in sloppy code anyway, it
On Wed, Oct 1, 2014 at 5:39 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt oli...@apple.com wrote:
JSC does lazy parsing of nested functions and we have no problem
reporting static errors, so i’m not sure what you believe is the problem
here.
Hi
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert that this cannot occur?
On Wed, Oct 1, 2014 at 8:59 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 8:39 AM,
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected statically,
why is a runtime assignment to a const variable even possible? Can't we just
assert that this cannot occur?
The runtime cases I meant are the ones you mentioned.
On Oct 1, 2014, at 9:43 AM, Oliver Hunt wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller erig...@google.com wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert that
On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert
On Oct 1, 2014, at 10:30 AM, Mark Miller wrote:
On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function f(value) { x = value; }
/script
script
use strict;
const x = 0;
f(1);
Hi,
(Maps are awesome!)
1. Transforming iteration methods
We're currently polyfillying the `Map`, and got some questions form devs.
One of them is about transforming iteration methods, like `map` and
`filter`.
Unfortunately I missed that part of the spec when it was approved, so can
someone
Claude Pache wrote:
The more I consider the issue, the more I think that the most elegant
solution is to complete data properties with an additional
overridable attribute, whose purpose is to refine the meaning of the
writable attribute in the manner sketched below (in opposition of
having an
Does the [[Overridable]] you have in mind also fix the override mistake? It
sounds like it should.
Regarding shadowable, is there any better documentation than the
doc-comment:
/* * For ES5 compatibility, we allow properties with
PropertyOp-flavored * setters to be shadowed when set. The
On Wed, Oct 1, 2014 at 11:57 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 2:50 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Hi,
(Maps are awesome!)
1. Transforming iteration methods
We're currently polyfillying the `Map`, and got some questions form
Mark S. Miller wrote:
Does the [[Overridable]] you have in mind also fix the override
mistake? It sounds like it should.
Yes, definitely.
Regarding shadowable, is there any better documentation than the
doc-comment:
|/*|
| * For ES5 compatibility, we allow properties with
Then thing is: if we'd like to use maps for such use-case, it brings us back
to that inconvenient imperative style of assignments (even worse, since you
have to repeat that `.set(...)` constantly):
```
var requestData = new Map();
requestData.set(Names.ID, id);
Not sure if this is sufficient motivation to accelerate the timeline for
adding suitable parallels from Array.prototype, but it may be worth
recalling what developers did last time there were obvious gaps in what a
native prototype provided. Array#contains, anyone?
On Wed, Oct 1, 2014 at 3:28
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate the timeline
It's not about motivation, it's about realistic time constraints. TC39
has already had to push out 6 months and that was not taken well by both
the
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate the timeline
It's not about motivation, it's about realistic time constraints. TC39
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate the timeline for
adding suitable parallels from Array.prototype, but it may be worth
recalling what developers did last time there were obvious gaps in what a
native
On Wed, Oct 1, 2014 at 4:17 PM, Axel Rauschmayer a...@rauschma.de wrote:
On Oct 1, 2014, at 22:12 , Axel Rauschmayer a...@rauschma.de wrote:
1. Transforming iteration methods
We're currently polyfillying the `Map`, and got some questions form devs.
One of them is about transforming
Ah, thanks! Then I’d wrap the result of `entries()` in `Array.from()`. In ES7,
we’ll hopefully be able to use comprehensions or iterator helper functions.
On Oct 1, 2014, at 22:27 , Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Oct 1, 2014 at 4:17 PM, Axel Rauschmayer
```js
let map2 = new Map(map1.entries().filter((key, value) = key = 0));
let map2 = new Map(map1.entries().map((key, value) = [key * 2, value *
2]));
entries() returns an iterator, not an array.
let map2 = new Map([...map1].map(([k, v]) = [k, v * 2])
Kevin Smith wrote:
entries() returns an iterator, not an array.
let map2 = new Map([...map1].map(([k, v]) = [k, v * 2])
Sweet!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Oct 1, 2014 at 4:38 PM, Axel Rauschmayer a...@rauschma.de wrote:
Ah, thanks! Then I’d wrap the result of `entries()` in `Array.from()`. In
ES7, we’ll hopefully be able to use comprehensions or iterator helper
functions.
Don't need to do that either.
let map1 = new Map([[-1, -1], [0,
On Wed, Oct 1, 2014 at 4:41 PM, Kevin Smith zenpars...@gmail.com wrote:
```js
let map2 = new Map(map1.entries().filter((key, value) = key = 0));
let map2 = new Map(map1.entries().map((key, value) = [key * 2, value *
2]));
entries() returns an iterator, not an array.
let map2 = new
Right.
Need a complete semantics: static and runtime. News at 11,
/be
Jason Orendorff wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function
Yup, and we've talked about this at TC39 meetings. We need a
simple-enough static analysis, and runtime errors for the residue that
escapes that analysis. I hope this is not controversial!
/be
Erik Arvidsson wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
I'd love to be able to get rid of SHADOWABLE, actually! I just
recently found out we can do it with a little rearranging. Extra
state-space in property attributes is unavoidable complexity for us.
My own preference would be not to standardize it. :)
There's also the [Replaceable] attribute in
On Wed, Oct 1, 2014 at 1:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate
On Wed, Oct 1, 2014 at 12:28 PM, Axel Rauschmayer a...@rauschma.de wrote:
Then thing is: if we'd like to use maps for such use-case, it brings us
back to that inconvenient imperative style of assignments (even worse,
since you have to repeat that `.set(...)` constantly):
```
var
Jason Orendorff wrote:
I'd love to be able to get rid of SHADOWABLE, actually! I just
recently found out we can do it with a little rearranging. Extra
state-space in property attributes is unavoidable complexity for us.
My own preference would be not to standardize it.:)
There's also the
On Wed, Oct 1, 2014 at 1:38 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Oct 1, 2014 at 4:26 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin
Dmitry Soshnikov wrote:
Not ideal either. Usually langs provide nice declarative syntax for
such things. E.g. we have[1] the same in the HACK language, and use it
well everyday when need a map.
But this part is of course not for ES6, hope ES7-ish.
[1]
On Wed, Oct 1, 2014 at 4:51 PM, Brendan Eich bren...@mozilla.org wrote:
Dmitry Soshnikov wrote:
Not ideal either. Usually langs provide nice declarative syntax for such
things. E.g. we have[1] the same in the HACK language, and use it well
everyday when need a map.
But this part is of
We could definitely have Map and Set literals:
const map = {1 = one, two = true, false = three};
Would that be tricky to parse if keys can be arbitrary expressions (incl. array
literals)?
const set = {1, two, false};
If you still buy Harmony of My Dreams, prefix # before { to get
Axel Rauschmayer wrote:
We could definitely have Map and Set literals:
const map = {1 = one, two = true, false = three};
Would that be tricky to parse if keys can be arbitrary expressions
(incl. array literals)?
The issue would be arrow function expression keys:
const map = {x = x*x =
48 matches
Mail list logo
